3 ms·

Yep, browsers should have screen readers built in. It's ridiculous that you have to shell out $1000+ for a JAWS license (there are alternatives, but they need w

by jbob2000 9y ago

Yep, browsers should have screen readers built in. It's ridiculous that you have to shell out $1000+ for a JAWS license (there are alternatives, but they need work).

SwellJoe 9y ago
Yeah, I've tried using the free options to sort of test my products, but it's not a realistic test; the most useful work comes from people who use screen readers daily, but it's really hard to test if we've fixed the problem even when it's been identified so we have to go back and forth. And, I mean, there are accommodations and assistive technology built into the standards. It's just nowhere near as widespread as it should be, in terms of usage, and it's always an afterthought (if it is thought of at all) in frameworks and HTML templates and such. And, because most of the time an inaccessible site or app is so inaccessible as to prevent anyone who would notice from getting far enough in to complain. So, we need good tools for knowing when our stuff is broken from an accessibility standpoint. I think what I'm getting at is that it should be easy to see errors in accessibility, and maybe search engines should favor sites that at least make an effort.
- extra88 9y ago
  The problem with testing with assistive technology yourself is you're not a real user who knows the tool well. Also, like browser testing, there are differences between different AT; VoiceOver is used by many visually impaired people but what it supports and how it works is different in a number of ways compared to JAWS or NVDA (e.g. VoiceOver doesn't have "form" and "browse" modes). Search engines giving more accessible sites a "buff" as Google now does for HTTPS sites is a good idea. They already do in a small way in that having things like proper headings are good for SEO but they could go much further. Google has their own Accessibility Developer Tools [0] add-on, they could make it a default part of Chrome Dev Tools and make it more prominent. https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en https://chrome.google.com/webstore/detail/accessibility-deve...
extra88 9y ago
Anyone who needs a screen reader needs it for accessing the whole device so building a screen reader into a browser is kind of pointless. The exception being Google's ChromeVox but that's because on Chromebooks the browser effectively is the OS. NVDA and Windows's Narrator are already probably good enough but JAWS is better. VoiceOver is built into macOS and iOS and is beyond good enough. Browsers can do a better job of exposing semantics through accessibility APIs to assistive technology [0]. Browsers could also intelligently make up for the failings of web sites; e.g. when a site uses a div with a click event instead of a button element, present it as a button through the accessibility API based on heuristics. Browser rendering engines already do a lot to visually compensate for errors in HTML, they could do the same for some semantic errors. [0] http://www.html5accessibility.com http://www.html5accessibility.com
seandougall 9y ago
Accessibility is more than just screen readers, too; e.g. there are OS-level settings for increased contrast and differentiation without color that are just about universally ignored on the web.

Yep, browsers should have screen readers built in. It's ridiculous that you have to shell out $1000+ for a JAWS license (there are alternatives, but they need work).

SwellJoe 9y ago

Yeah, I've tried using the free options to sort of test my products, but it's not a realistic test; the most useful work comes from people who use screen readers daily, but it's really hard to test if we've fixed the problem even when it's been identified so we have to go back and forth. And, I mean, there are accommodations and assistive technology built into the standards. It's just nowhere near as widespread as it should be, in terms of usage, and it's always an afterthought (if it is thought of at all) in frameworks and HTML templates and such. And, because most of the time an inaccessible site or app is so inaccessible as to prevent anyone who would notice from getting far enough in to complain. So, we need good tools for knowing when our stuff is broken from an accessibility standpoint. I think what I'm getting at is that it should be easy to see errors in accessibility, and maybe search engines should favor sites that at least make an effort.

extra88 9y ago
The problem with testing with assistive technology yourself is you're not a real user who knows the tool well. Also, like browser testing, there are differences between different AT; VoiceOver is used by many visually impaired people but what it supports and how it works is different in a number of ways compared to JAWS or NVDA (e.g. VoiceOver doesn't have "form" and "browse" modes). Search engines giving more accessible sites a "buff" as Google now does for HTTPS sites is a good idea. They already do in a small way in that having things like proper headings are good for SEO but they could go much further. Google has their own Accessibility Developer Tools [0] add-on, they could make it a default part of Chrome Dev Tools and make it more prominent. https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en https://chrome.google.com/webstore/detail/accessibility-deve...

extra88 9y ago

Anyone who needs a screen reader needs it for accessing the whole device so building a screen reader into a browser is kind of pointless. The exception being Google's ChromeVox but that's because on Chromebooks the browser effectively is the OS. NVDA and Windows's Narrator are already probably good enough but JAWS is better. VoiceOver is built into macOS and iOS and is beyond good enough. Browsers can do a better job of exposing semantics through accessibility APIs to assistive technology [0]. Browsers could also intelligently make up for the failings of web sites; e.g. when a site uses a div with a click event instead of a button element, present it as a button through the accessibility API based on heuristics. Browser rendering engines already do a lot to visually compensate for errors in HTML, they could do the same for some semantic errors. [0] http://www.html5accessibility.com http://www.html5accessibility.com

seandougall 9y ago

Accessibility is more than just screen readers, too; e.g. there are OS-level settings for increased contrast and differentiation without color that are just about universally ignored on the web.