> Respect my font settings? My system Theme and accessibility settings? In theory zooming should be easier, but in partice it isn't. My keyboard settings more than a canvas?
Yes, specifying shortcuts and fonts at the browser level is better than doing it application by application. Browser zoom is usually vastly preferable to just magnifying the screen in my experience. Handling gestures, intercepting all keyboard events (including right click menus), and reimplementing settings like smooth scrolling on canvas is much more difficult and will give you much worse performance than just letting the browser do it for you, because you'll have to reinvent the wheel for every input.
A good example of this is multitouch. Many websites were written before touchscreens were common. Most of those websites work with touch scrolling on my tablet, even though they haven't been updated. If you bundle an application with Qt and 2 or 3 years from now a new input format becomes commonplace, your site won't work with it unless you recompile and re-ship because it's up to you to interpret every piece of raw input that you get.
Add to that the fact that many browsers handle input differently because different devices call for different behaviors. On sites that aren't optimized for mobile, your phone browser uses extra logic to make sure that your clicks are intentional. If you're manually handling everything yourself via canvas, you can't do that without trying to guess what device a user is using - an increasingly difficult task.
> Is is really easier for a screenreader to navigate thru thousands of divs (with CSS!) and images with no alt text then just take a image and OCR it?
It's way easier. You're talking about using some kind of Machine Learning system or algorithm to take the place of explicit accessibility controls.
Programs like Jaws do so much more than just read text off a page. They allow you to jump and scroll to specific headings. They allow you to get a list of every link on a page. They allow you to fill out an item on a form and jump to the submit button with a key stroke that you define (not the webapp) - or select an input field and read off the associated label or help box attached to it.
There's a huge list of Aria labels and tricks that are used to make the DOM accessible, and none of them work with OCR - hidden icon labels, alt tags for images, etc...
Accessibility is not just about reading off random text on a page. It's about context. The reason why a blob of pixels isn't accessible is because anyone who's blind loses all of the context. You lose the ability to take a hunk of content in your application and say in a universal language that every screen reader will understand, "This is the navigation. Bring the user here if they want to go somewhere."
That stuff doesn't stop being important just because you made an application - arguably, it's much more important for an application than it is for a blog post or document. For a blog post you could make the argument that as long as your screen reader reads the text in order, you're still getting the gist of everything.
For an application, a blind user needs much more context and much better structure than would otherwise be required for just reading.
I've built enterprise level web applications - for us to say that we were compliant with accessibility standards, we had to do a heck of a lot more than just allow people to read text. The DOM helps with that.
Yes, specifying shortcuts and fonts at the browser level is better than doing it application by application. Browser zoom is usually vastly preferable to just magnifying the screen in my experience. Handling gestures, intercepting all keyboard events (including right click menus), and reimplementing settings like smooth scrolling on canvas is much more difficult and will give you much worse performance than just letting the browser do it for you, because you'll have to reinvent the wheel for every input.
A good example of this is multitouch. Many websites were written before touchscreens were common. Most of those websites work with touch scrolling on my tablet, even though they haven't been updated. If you bundle an application with Qt and 2 or 3 years from now a new input format becomes commonplace, your site won't work with it unless you recompile and re-ship because it's up to you to interpret every piece of raw input that you get.
Add to that the fact that many browsers handle input differently because different devices call for different behaviors. On sites that aren't optimized for mobile, your phone browser uses extra logic to make sure that your clicks are intentional. If you're manually handling everything yourself via canvas, you can't do that without trying to guess what device a user is using - an increasingly difficult task.
> Is is really easier for a screenreader to navigate thru thousands of divs (with CSS!) and images with no alt text then just take a image and OCR it?
It's way easier. You're talking about using some kind of Machine Learning system or algorithm to take the place of explicit accessibility controls.
Programs like Jaws do so much more than just read text off a page. They allow you to jump and scroll to specific headings. They allow you to get a list of every link on a page. They allow you to fill out an item on a form and jump to the submit button with a key stroke that you define (not the webapp) - or select an input field and read off the associated label or help box attached to it.
There's a huge list of Aria labels and tricks that are used to make the DOM accessible, and none of them work with OCR - hidden icon labels, alt tags for images, etc...
Accessibility is not just about reading off random text on a page. It's about context. The reason why a blob of pixels isn't accessible is because anyone who's blind loses all of the context. You lose the ability to take a hunk of content in your application and say in a universal language that every screen reader will understand, "This is the navigation. Bring the user here if they want to go somewhere."
That stuff doesn't stop being important just because you made an application - arguably, it's much more important for an application than it is for a blog post or document. For a blog post you could make the argument that as long as your screen reader reads the text in order, you're still getting the gist of everything.
For an application, a blind user needs much more context and much better structure than would otherwise be required for just reading.
I've built enterprise level web applications - for us to say that we were compliant with accessibility standards, we had to do a heck of a lot more than just allow people to read text. The DOM helps with that.