Techniques

Test key journeys and any new areas

Ensure that frequently used and newly designed parts of the site are given high priority in testing.

Include users with different access needs in your testing

While screen reader users are often front of mind when considering accessibility, you also need to consider how well your site works for users with other disabilities or impairments.

It can be difficult to create prototypes that work with screen readers, as they do not tend to use “semantic coding”, so headings are not coded (and therefore nor are they conveyed to screen reader users) as headings, however it is still important to test other aspects of your site for accessibility with users who, for example, have impaired vision (including screen magnification users), mobility, dexterity, hearing or cognitive impairments.

If you are familiar with the behaviours of a particular screen reader that someone in your testing is going to use, you can test with screen reader users quite effectively:

  • Include some of those behaviours in the text of your prototype, for example by prefixing the text in your main heading with “Heading level one: ” – this still will not appear in a list of headings but it will allow screen reader users to read your content in a linear manner and will provide useful insight;
  • The moderator can “be” the assistive technology – if a screen user calls up a list of headings (which will be empty) they can read them out and put the focus in the right place on the page for them – the moderator must be very clear about what they are going to do though, so as not to confuse the test participant! 

Here are some access needs that it is important test your designs with:

  • Users who have reduced or partial vision, as well as those who are blind;
  • Users who are fully sighted but who navigate with a keyboard;
  • Users who are able to use a keyboard and/or mouse, but at a reduced speed due to motor impairments;
  • Users who use alternative input devices (such as mouth sticks, joysticks, or trackballs);
  • Users who are deaf or hard of hearing;
  • Users with cognitive or memory impairments ;
  • Users with lower literacy, or reading difficulties such as dyslexia;
  • Users for whom the primary language of your site is not their primary language.

Avoid relying solely on automated accessibility testing software

Automated software is very good at certain things that are time-consuming for humans to do, such as checking contrast ratios of text and its background. Automated software is not good at other things where a degree of interpretation is required, such as “Is this Alt text appropriate for the image?”; “Does the heading text reflect the content?”; “Should this content really be presented as a list?”. Use automated software in the evaluation of your designs but do not rely solely on it.

Seek expert advice

Some agencies may be able to help with accessibility evaluations and audits. Whilst these are often important activities, you should also consider paying for a day of consultancy time from someone who has an access need, prior to usability testing. They will be able to point out any barriers and any positive aspects of your designs, allowing you to consider and address them prior to testing.

Videos

Further reading