Hi Erin,
 
22.03.2015, 22:11, "Erin Prichard" <ERPrichard@blindfoundation.org.nz>:

Apologies if this has been asked before, but would appreciate any guidance.

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.

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?

Proposed:

JAWS is the optimised reader

NVDA as a supported reader

Windows-Eyes as a supported reader

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.
 
Audience:
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.
 
Budget:
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).
 
Developer Skill:
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.
 
 

2. What browsers to support and versions of each? 

Proposed:

IE 11 – optimised

IE 8 – supported

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.

Chrome – supported

Firefox – supported

Safari 8.0.3 -  optimised

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…
 
cheers
 
chaals
 
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com