I think this is actually a great example on the potential pit-falls of going with this approach. This isn't really accessible and shows how even a large company

I think this is actually a great example on the potential pit-falls of going with this approach. This isn't really accessible and shows how even a large company with a lot of resources can miss the mark. For example, if I try to have VoiceOver (control + option + w) read the word I am currently on in Google Docs, it doesn't work, Using VoiceOver's search (control + option + f in Safari) doesn't work, basically nothing actually seems to work from what I can tell. A visual user can easily scan a document and find a heading, where a VoiceOver user might search to jump to it instead. While they do provide some keyboard shortcuts to help navigate a document easier, this is not a valid substitute for supporting the screenreader the way users know how to use / are proficient with. While a user of a screenreader could technically use it, it isn't usable (or accessible) in any real sense of the word. If you were to translate this to a visual user experience, imagine you could only see one letter at a time and can go forwards/backwards one character. It seems like they are using an `aria-live` region to speak where you are rather than having a separate DOM representation of the content and syncing the state (which can be an engineering effort most companies / libraries cannot afford invest enough to get completely right). Disclaimer: I am not a primarily a screenreader user, though I do have some experience using them. Disclaimer: I used to work at Google, though not on Docs.