5

As a front-end developer in a small business agency ( < 30 developers) I am trying to be better at accessibility testing and screen-readers are a must then.

I am a Windows user and also has access to a MAC and therefore I try to use NVDA (and Microsoft Narrator) and then go to MAC and use it's Voice over. Always feeling not quite 100% if my tests are good enough as I am not experienced screen-reader user and after reading a lot on them I found this useful page; https://webaim.org/articles/screenreader_testing/ - finding myself in this sentence here;

Screen reader users are one of the primary beneficiaries of your accessibility efforts, so it makes sense to understand their needs. Of course, you don't want to fall into the trap of thinking that accessibility is only relevant to screen reader users.

So - now to the question: how do you and your company cope with screen-reader testing ?

Do you have the needed competence level or do you out-source this (I think this needs to be tested manually but maybe somebody uses some advanced automatic tests too)?

And I found this one on MS Narrator:

Windows Narrator is not a real screen reader, it is a toy!

(https://stackoverflow.com/a/27756562/3365805) - but now we are in 2020 and I would like to think that MS Narrator should be "better" - what are your experiences here?

The objective here is of course 100% WCAG 2.0 A and 2.1 A compliancy (AA too in some cases).

1 Answer 1

3

I wouldn't bother with Narrator too much but by all means add it to your testing suite.

You will see from the webAim screenreader study that NVDA, JAWS and VoiceOver make up over 90% of screen readers. So those are the ones we use in testing. You will see narrator makes 1%.

The thing is if you can make a site that is accessible and fully usable in NVDA, JAWS and VoiceOver then it should work in other screen readers also.

In terms of experience using a screen reader it is actually beneficial that you are not experienced (explained later).

We tend to do all primary testing in NVDA, then just use VoiceOver and JAWS at the final stage to tidy up any idiosyncrasies with those screen readers.

Testing is done in two stages, component stage and page stage.

In component stage we design a component (i.e. an auto complete search box) and then test specific features, key combinations that fall under 'expected behaviour' and general usability.

Please note we do a battery of tests not just screen reader tests (focus indicator visible, colour contrast, screen magnifier at 800% zoom (to check labels, tooltips etc. are close enough to things and don't interfere) etc.)

Then we do full page tests which are 'functional' tests - i.e. we set specific goals (navigate to page x, fill in form y but make mistakes and check it is clear what mistakes were made etc.).

Between these two types of testing by the time you come to launch a website / web app there is nothing to do (and it adds maybe 2% extra time to development doing it this way, possibly as high as 10% if you have only just started on accessibility as a company as a lot of things will need redesigning that you use on a regular basis. However over time you will build up a base library and coding guidelines that are accessible by default).

I always make sure I stick to core commands when testing. This is because that is the minimum level of knowledge you need to use a screen reader with just the keyboard, so should be the minimum level of knowledge one of your site visitors will have.

As such your 'lack of experience' is actually a good thing.

So should we outsource?

Everything I have said makes it sound like you should do things in-house, and in an ideal world you should.

However there is a problem with this, the same as any other UX scenario. You end up developing bad habits and think 'I know how to use this component so everyone should be able to use it'.

What I would recommend is that you do preliminary testing in-house, get the site to a stage you think it is accessible and then employ a company to do user testing. They will approach the software 'blind' (no pun intended) and so they will not know the layout of pages etc. This is really beneficial as it shows holes in your logic and lets you see where a particular design aspect is not as clear as you think.

Testing Tips

Build a checklist

For the technical aspects of the design, complying with WCAG etc. a checklist is a great way to make accessibility testing easy.

We split our into component types, page theme, navigation and technical so that we can pull an applicable checklist without having to try and remember every single rule (which I still can't do!)

Build personas

gov.uk have a great writeup on accessibility personas along with a github repository with this in. Basically test against different people's needs. This is a great testing method and thought process for the team as well.

Different browser and screen reader combinations

Title says it all, JAWS works better with Internet Explorer, NVDA works best with FireFox etc. Try 'switching it up' to make sure it works on as wide a range of combinations of browser and screen reader as possible.

Give yourself minus marks for using WAI-ARIA

Yup you heard me right, points off for using WAI-ARIA.

This is a bit tongue-in-cheek but the actual point of this rule is to encourage you to think about native HTML5 components. I see lots of people adding a div with role="region" - just use a region, use buttons for buttons etc.

WAI-ARIA is not as widely supported as you think so use it for extra information, if your component is impossible to use without WAI-ARIA it is often 'code stink' that you are doing it a more difficult way.

Use WAI-ARIA but don't rely on it to make a site accessible, very few scenarios cannot be created with native components.

Conclusion

Accessibility testing is hard. Building accessibility into development practices is harder....at first.

When testing if you find a particular accessibility issue more than once then write some coding guidelines around it.

If you do that, coupled with checklists, personas etc. you will take about 6-12 months to transition to an 'accessibility first' way of thinking. As an added bonus you will probably design much better User Interfaces and a much better User Experience!

2
  • thank you very much for this deep insight. I got some of my theories confirmed and that feels good when one begins with such an important task. I can feel that everybody feels that A11y is good but almost every developer and designer needs a reminder or two, me included. Therefore I made it my business to advocate A11y internally and to our customers too as they share the burden. Learning about a11y for quite some years now and I think it is perfectly doable, I am just skeptical about the screen-reader part as I have seen it can be really advanced and critical. Thank you! May 12, 2020 at 18:14
  • Not a problem, keep pushing for accessibility and if you ever need help making the business case for it that is how I spend most of my days, showing managers and owners the benefits of integrating accessibility into development practices, so happy to give you some ammo (as you will have arguments at first :-) May 13, 2020 at 7:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.