3 ms·

Google is using canvas for Google Docs. They can also activate using HTML elements for screen readers. Nobody in open source component development should be dis

Google is using canvas for Google Docs. They can also activate using HTML elements for screen readers. Nobody in open source component development should be discouraged from building the canvas side of things so web app/site developers can do the same thing. It's up to the web app/site developer to make sure there's always an alternative to canvas components. Where practical, the canvas component should provide the accessible alternative, but sometimes the is better done by external component(s). https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

zat 5y ago
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.
- hoten 5y ago
  Did you enable the screen reader features? apparently they are behind a kb shortcut: https://imgur.com/pSLYLcd https://imgur.com/pSLYLcd (btw: I got this a11y tree view by enabling a new experiment in the devtools)
  - zat 5y ago
    Yep, I enabled it. The rest of the UI is fine as it seems to use regular HTML so it will show up in the accessibility tree. The problem is the text editing area itself which uses canvas.
- mwcampbell 5y ago
  Did you turn on screen reader mode or braille mode in Google Docs? IIUC, braille mode exposes more UI content and structure to a screen reader, as opposed to simply feeding it text to speak. Not sure why braille mode isn't the only screen reader mode; maybe it's slower.
rikroots 5y ago
Concerning the inaccessibility of the <canvas> element, I've done a lot of work with my JS canvas library[1] to try and make canvas-based infographics, animations, etc more accessible[2]. I've also written up a lesson on how to build an accessible canvas scene which some might find useful[3]. [1] - Obligatory link to Scrawl-canvas library (on GitHub): https://github.com/KaliedaRik/Scrawl-canvas https://github.com/KaliedaRik/Scrawl-canvas [2] - Sadly I don't have any evidence that my library's solutions help people with accessibility needs in the real world, because nobody seems interested in using it. I live in hope that this may change one day. [3] - Accessible canvas lesson: https://scrawl-v8.rikweb.org.uk/learn/eleventh-lesson https://scrawl-v8.rikweb.org.uk/learn/eleventh-lesson

zat 5y ago

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.

hoten 5y ago
Did you enable the screen reader features? apparently they are behind a kb shortcut: https://imgur.com/pSLYLcd https://imgur.com/pSLYLcd (btw: I got this a11y tree view by enabling a new experiment in the devtools)
- zat 5y ago
  Yep, I enabled it. The rest of the UI is fine as it seems to use regular HTML so it will show up in the accessibility tree. The problem is the text editing area itself which uses canvas.
mwcampbell 5y ago
Did you turn on screen reader mode or braille mode in Google Docs? IIUC, braille mode exposes more UI content and structure to a screen reader, as opposed to simply feeding it text to speak. Not sure why braille mode isn't the only screen reader mode; maybe it's slower.

rikroots 5y ago

Concerning the inaccessibility of the <canvas> element, I've done a lot of work with my JS canvas library[1] to try and make canvas-based infographics, animations, etc more accessible[2]. I've also written up a lesson on how to build an accessible canvas scene which some might find useful[3]. [1] - Obligatory link to Scrawl-canvas library (on GitHub): https://github.com/KaliedaRik/Scrawl-canvas https://github.com/KaliedaRik/Scrawl-canvas [2] - Sadly I don't have any evidence that my library's solutions help people with accessibility needs in the real world, because nobody seems interested in using it. I live in hope that this may change one day. [3] - Accessible canvas lesson: https://scrawl-v8.rikweb.org.uk/learn/eleventh-lesson https://scrawl-v8.rikweb.org.uk/learn/eleventh-lesson