Apologies if this has been asked before, but would appreciate any guidance.
Work is being undertaken to make our website more accessible, and we have the following questions…
1. What screen readers should we be looking to support and what versions of each?
JAWS is the optimised reader
NVDA as a supported reader
Windows-Eyes as a supported reader
2. What browsers to support and versions of each?
IE 11 – optimised
IE 8 – supported
Chrome – supported
Firefox – supported
Safari 8.0.3 - optimised
Thanks in advance !
Donate to Red Puppy Appeal
and help puppies like Sid become a guide dog. He can't do it without you!
Erin Prichard composed on 2015-03-22 21:03 (UTC):
> Firefox - supported
Firefox isn't appropriate for a "supported" browsers category.
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Actually...Gecko may be the underlying engine, but for accessibility support it's important that the actual overall browser itself has the right hooks into the platform's accessibility APIs and exposes the correct information. So specifying Firefox, rather than Gecko in general, is in fact correct. See also various browsers on Android which use Blink, but are completely inaccessible compared to Chrome.
Patrick H. Lauke
> On 22 Mar 2015, at 21:28, Felix Miata <[hidden email]> wrote:
> Erin Prichard composed on 2015-03-22 21:03 (UTC):
>> Firefox - supported
> Firefox isn't appropriate for a "supported" browsers category.
> http://geckoisgecko.org/ explains.
> "The wise are known for their understanding, and pleasant
> words are persuasive." Proverbs 16:21 (New Living Translation)
> Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> Felix Miata *** http://fm.no-ip.com/
In reply to this post by Erin Prichard
Just curious how you are defining “supported” vs “optimised” in this context?
In reply to this post by Erin Prichard
22.03.2015, 22:11, "Erin Prichard" <[hidden email]>:
Everyone should be telling you that as far as possible, you should be making it accessible to any system.
In particular, using design patterns that are known to be problematic for accessibility, and then finding a specific workaround to make something work in e.g. JAWS and NVDA is basically a stupid approach. A classic example is hiding links from sighted users, with something that makes them appear to screen readers but confuses the heck out of magnifier users who simply lose any idea of where they are in a page, and what will happen if they continue.
But of course reality intrudes when you do real work. So assuming you have started from a basis of "let's not try to justify dumb ideas, but to make the site work sensibly", your question is still important for things like specific screenreader and/or browser bugs.
This should really be based on looking at your audience, your budget, and the skills of your developers. It would be nice if the last two covered anything you might want, but I find that scenario unlikely enough to reject it out of hand.
This is tricky. Having seen inside the makings, I would advise great caution in dealing with statistics that you find.
For example, I believe New Zealand, like Australia, has an unusually high proportion of Apples, iPhones and iPads. I'm surprised that you don't propose VoiceOver as a primary target. But it may be the case that Android has a huge support network in NZ's blind community meaning it's the most popular overall way to browse, and should therefore be supported.
Focus on maintainable, and how deep a change you can make at a reasonable cost. The browser market changes on a cycle of a couple of years, screen readers actually faster, despite a lot of inertia - which I presume you recognised in listing IE8 as supported. Don't get caught with something that can't support the market six months after you got it delivered… (That's not accessibility-specific, of course).
One thing that is important is differentiating between "requirements" and opportunities. Good developers will be able to do a lot to broaden the net of support, making the site workable even if not optimal on a wide range of platforms, and will be able to provide specific enhancements for certain things basically free. Know where that applies to you and take advantage of the expertise. But of course if it seems odd, before adopting a particular person's pet feature it isn't a bad idea to check that it works as advertised and isn't a bad idea…
Possibly more important than making sure you cover multiple screen readers, if your basic design approach is sound, is making sure you cover multiple use-patterns for assistive technology. Screen-readers are of course used by people who can't see at all, but are also used by people with dyslexia or with some level of vision - and generally in somewhat different ways.
Again by way of example, the issues you will encounter are different levels of knowledge about functionality the screen reader has, and perhaps different patterns of use based on combining it with some other tool such as magnification.
It is worth considering the position of IE8 in enterprise and government or government-ish systems. In some places, the reality is that this is a critical support requirement.
This makes me even more curious about why you don't list VoiceOver in the screen reader section.
For what it's worth, my own anecdotal experience is that in my situation I would want to support VoiceOver on iOS as well as possible but basically wouldn't worry about it on desktop - in part because doing the first bit mostly covers the latter and in part because in my particular situation I find blind screen reader users focused on iPhones and Windows desktops. Although this is not true for other screen reader users, that gets covered well enough for me by making the iPhone work.
Good luck, in any case. Whatever you do, don't let perfect be the enemy of good…
Charles McCathie Nevile - web standards - CTO Office, Yandex
[hidden email] - - - Find more at http://yandex.com
In reply to this post by email@example.com
For contractual purposes, we maintain a "Generic Assistive Technology and Information Technology (AT/IT) Environment List". Unless otherwise specified, testing is against the most recent versions, but it is frequenting expanded based on who will be using the website or application. Contracts require compliance with the standards, so at some point testing different versions of operating systems, browsers, and AT just becomes an exercise in finding bugs or the capabilities of (for operating systems) or interaction with (for browsers and AT) accessibility APIs.
Sarah E. Bourne
Director of IT Accessibility, MassIT
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
|Free forum by Nabble||Edit this page|