3 ms·

You can have accessibility without the DOM, and really the DOM is not such a great way to do this anyway. Just do things like write explicit audio-only interfac

You can have accessibility without the DOM, and really the DOM is not such a great way to do this anyway. Just do things like write explicit audio-only interfaces.

bzbarsky 12y ago
That's a pretty narrow view of "accessibility". For example, you just assumed that your user can't see (or can't see very well?) but can hear. Users who are deaf and blind? Out of luck. Users who are deaf and not blind but need your thing zoomed to a larger size? Maybe out of luck maybe not (depends on whether the WebGL app detects browser zoom and actively works to defeat it like some do). Users who are deaf and not particularly blind but happen to not be able to tell apart the colors you chose to use in your WebGL? Also out of luck. What the DOM gives you is a semantic representation that the user can then have their user agent present to them in a way that works best for them. Reproducing that on top of WebGL or canvas really is quite a bit of effort if you really want to target all users and not just a favored few groups.
tree_of_item 12y ago
I can't reply to bzbarsky for some reason, but: I assumed we were talking about vision impairment, because that's what the comment I replied to mentioned. Of course you can implement whatever else you want as well. I question this "semantic DOM" idea: the trend has been towards filling the DOM with tons of crap in order to make applications, not documents. Do accessibility agents even work well on JavaScript heavy sites today? Accessibility can and will be had without the DOM; while it is a concern, it shouldn't prevent things like WebGL + asm.js apps on the web.
- bzbarsky 12y ago
  No idea why you couldn't reply to me, but.... My point is that visual impairment is not mutually exclusive with other impairment, even though people often assume it is, consciously or not. This is an extremely common failure mode, not just in this discussion. And while of course you _can_ implement whatever else you want, in practice somehow almost no one ever does. Doubly so for the cases they don't think about or demographics they decide are too small to bother with. How well accessibility agents work on JS heavy sites today really depends on the site. At one end of the spectrum, there are JS heavy sites that still use built-in form controls instead of inventing their own, have their text be text, and have their content in a reasonable order in the DOM tree. At the other end there are the people who are presenting their text as images (including canvas and webgl), building their own <select> equivalents, absolutely positioning things all over the place, etc. Those work a lot worse. You are of course right that accessibility can be had without the DOM, but "webgl" is not going to be it either. Accessibility for desktop apps typically comes from using OS-framework provided controls that have accessibility built in as an OS service; desktop apps that work in low-level GL calls typically end up just as not-accessible as your typical webgl page is today. So whatever you want use instead of the DOM for accessibility purposes really will need to contain more high-level human-understandable information than which pixels are which colors or what the audio waveform is. At least until we develop good enough AI that it can translate between modalities on the fly.
  - amelius 12y ago
    Speaking about AI, is it really that hard to do the OCR'ing of the images? I'm no expert, but I was under the impression hat this was a solved problem.
- SixSigma 12y ago
  > I can't reply to bzbarsky for some reason there's a rate limit to stop threads exploding

You can have accessibility without the DOM, and really the DOM is not such a great way to do this anyway. Just do things like write explicit audio-only interfaces.

bzbarsky 12y ago

That's a pretty narrow view of "accessibility". For example, you just assumed that your user can't see (or can't see very well?) but can hear. Users who are deaf and blind? Out of luck. Users who are deaf and not blind but need your thing zoomed to a larger size? Maybe out of luck maybe not (depends on whether the WebGL app detects browser zoom and actively works to defeat it like some do). Users who are deaf and not particularly blind but happen to not be able to tell apart the colors you chose to use in your WebGL? Also out of luck. What the DOM gives you is a semantic representation that the user can then have their user agent present to them in a way that works best for them. Reproducing that on top of WebGL or canvas really is quite a bit of effort if you really want to target all users and not just a favored few groups.

tree_of_item 12y ago

I can't reply to bzbarsky for some reason, but: I assumed we were talking about vision impairment, because that's what the comment I replied to mentioned. Of course you can implement whatever else you want as well. I question this "semantic DOM" idea: the trend has been towards filling the DOM with tons of crap in order to make applications, not documents. Do accessibility agents even work well on JavaScript heavy sites today? Accessibility can and will be had without the DOM; while it is a concern, it shouldn't prevent things like WebGL + asm.js apps on the web.

bzbarsky 12y ago
No idea why you couldn't reply to me, but.... My point is that visual impairment is not mutually exclusive with other impairment, even though people often assume it is, consciously or not. This is an extremely common failure mode, not just in this discussion. And while of course you _can_ implement whatever else you want, in practice somehow almost no one ever does. Doubly so for the cases they don't think about or demographics they decide are too small to bother with. How well accessibility agents work on JS heavy sites today really depends on the site. At one end of the spectrum, there are JS heavy sites that still use built-in form controls instead of inventing their own, have their text be text, and have their content in a reasonable order in the DOM tree. At the other end there are the people who are presenting their text as images (including canvas and webgl), building their own <select> equivalents, absolutely positioning things all over the place, etc. Those work a lot worse. You are of course right that accessibility can be had without the DOM, but "webgl" is not going to be it either. Accessibility for desktop apps typically comes from using OS-framework provided controls that have accessibility built in as an OS service; desktop apps that work in low-level GL calls typically end up just as not-accessible as your typical webgl page is today. So whatever you want use instead of the DOM for accessibility purposes really will need to contain more high-level human-understandable information than which pixels are which colors or what the audio waveform is. At least until we develop good enough AI that it can translate between modalities on the fly.
- amelius 12y ago
  Speaking about AI, is it really that hard to do the OCR'ing of the images? I'm no expert, but I was under the impression hat this was a solved problem.
SixSigma 12y ago
> I can't reply to bzbarsky for some reason there's a rate limit to stop threads exploding