We have a heavy documentation culture at Stripe so as a developer these tools matter a lot.
We have a heavy documentation culture at Stripe so as a developer these tools matter a lot.
Google Docs works, there are two accessibility modes, none of which is enabled by default. The old, standard mode hides all content from screen readers and uses a built-in micro screen-reader that outputs whatever is needed to a live region, which your screen reader then reads. The newer one, called braille mode, actually shows you the content, only relying on ARIA when absolutely necessary. Both have their pros and cons, but I'd recommend using Braille Mode for most things, unless you run into use cases that the legacy mode handles better.
I've heard people say that some really advanced docs features have accessibility issues, but I haven't used it that extensively to confirm that.
As always, Etherpad, the open source / non-proprietary / privacy-friendly alternative boasts about being accessible but has so many a11y bugs that it's basically unusable. As always, markdown over git works better than any web-based solution ever could.
Accessibility at Google suffers in the same way as most UX-related things suffer at Google. Namely, the fact that everything is constantly reinvented from scratch, rather than there being one unified way to do it. As a screen reader user, I can say that in some Google products, there can be instances of what, on the surface, should be exactly the same component, but was apparently developed in multiple different ways. This leads to the constant need to work out how accessible each instance is (and e.g. what keyboard support it has), even though I dealt with the same UI pattern minutes ago.