Open in app

Sign in

Write

Sign in

Accessibility Manual Testing

Step-by-step guide for testers on how to deal with the accessibility.

Andrey Enin
9 min readAug 29, 2021

There are many articles for web developers about accessibility and hundreds of pages of detailed documentation. But when the task of accessibility testing turns out to be on the side of the Quality Assurance department, this information should be transformed into the requirements of users with disabilities.

This article covers some testing vectors if a test engineer has to perform an accessibility audit.

Disclaimers:

  • I assume that the reader is familiar with the concept of accessibility (A11y) and technologies of its implementation (see references at the end of the article);
  • The article does not cover automated testing;
  • The basic checks listed below execute without using a screen reader;
  • As an example, a page of an album on Yandex Music was selected.
Test page
Test page

Keyboard Navigation

The first set of tests is aimed at what can be seen with the eyes and reproduced without additional tools.

1. Focus on Interactive Elements

Try to navigate through the page by TAB key. Pay attention to the selection of active elements during navigation — interactive elements should be focusable. Users should clearly understand where they are on the site.

Actual result:

  • All buttons and links do not have focus;
  • Most of the elements have the property outline: 0px, which is an antipattern.
1.1. Focus on interactive elements — there is no focus on the marked items, the users do not understand where they are located
1.1. Focus on interactive elements — there is no focus on the marked items, the users do not understand where they are located

Expected: if the element is interactable, it will have a visible indication.

1.2. Focus on interactive elements — the [contemporary jazz] link has a default focus style
1.2. Focus on interactive elements — the [contemporary jazz] link has a default focus style

Wherefore? The highlighted focus is visual feedback for the users.

This is 2.4.7 «Focus Visible» WCAG requirement (more info).

It is recommended to provide an obvious focus style (especially if the default one is removed):

2. Sequence of Elements During Tabbing

Navigate through the page by TAB key. Interactive elements should be selected from left to right and from top to bottom.

The actual result matches with expected: navigation takes place in a logical sequence. The visual order of the elements corresponds to the real order in the DOM-tree and CSS properties do not change the order of elements.

This is 1.3.2 «Meaningful Sequence» and 2.4.3 «Focus order» WCAG requirements (more info).

3. TAB Order

Navigate through the page by TAB key. All interactive content should be intractable.

Actual result:

  • Search button is missing for keyboard navigation. Users without a mouse or touchpad are unable to make a search request on the site.
  • It is impossible to play an arbitrary track from the album. Interactive elements ([play], [like], and [dislike] buttons) are not a part of the tab order, and they appear only when the user hovers a mouse over them.
3. TAB order — [play] buttons are not available for keyboard navigation
3. TAB order — [play] buttons are not available for keyboard navigation

Expected: interactive content is intractable.

Wherefore? To use all functions of the website.

This is 2.1.1 «Keyboard» WCAG requirement (more info).

Elements can be included or excluded from the tab order by tabindex value.

4. Tabindex Values

Check the values of the tabindex attributes in the page’s source code.

Actual result: multiple elements with tabindex > 0.

Expected: the only one element with tabindex > 0.

Wherefore? In order not to confuse the browser or to specify the first focus element (when using only one tabindex = 1).

Despite that the tabindex can be greater than 0 (but not exceed 32767), it is recommended to have a single element with tabindex > 0, because it will be the first one to receive focus from the keyboard by TAB.

Semantics

The second set of tests is aimed at how the site is ready to work with assistive technologies.

5. Language Declaration

Yandex Music has localisation — the page language could be changed into Russian, Armenian, Uzbek, Kazakh, Ukrainian, or Azerbaijani. Therefore, you need to check the declaration of the page language.

Actual result: <html> tag does not have any attributes.

Expected: <html lang="en">.

Wherefore? To help a speech synthesizer accurately determine the language of the page.

Each language locale must correspond to the value from the IANA registry: ru, hy, uz, kk, uk, or azb.

6. Document Structure

Check for the appropriate section heading elements.

The actual result matches with expected: titles are marked with the correct tags.

6. Document structure — the main title is <h1>Round one</h1>
6. Document structure — the main title is <h1>Round one</h1>

Wherefore? A well-thought-out structure of the document will help users to navigate through the page, because screen readers allow fast switching between headings.

This is 1.3.1 «Info and Relationships» WCAG requirement (more info).

If the layout consists of only <div>s, it is still possible to include them into A11y-tree by adding the corresponding ARIA roles: role= "heading" aria-level= "1".

7. Landmarks

Check for ARIA Landmark Roles attributes in the page’s source code.

Actual result: nothing.

Expected: page areas are marked up by the main ARIA roles in accordance with their content: banner, complementary, contentinfo, main, navigation, search.

7. Landmarks — example of ARIA Landmarks Roles
7. Landmarks — example of ARIA Landmarks Roles

Wherefore? Landmarks, same as semantic headers, will help users to navigate through the page, because screen readers allow fast switching between landmarks.

This is 1.3.6 «Identify Purpose» WCAG requirement (more info).

Landmarks determine the purpose of the page areas and, in a way, duplicate content sectioning HTML5 elements: <header>, <aside>, <footer>, <main>, <nav>. However, it is still necessary to specify HTML5 tags by additional ARAI roles to support older browsers and bypass bugs.

8. Interactive Content Description

Check the presence and clarity of the description of interactive elements (buttons and links). It is useful to try a screen reader to better understand how the text will be read.

Actual result: there are no descriptions, or they are incomprehensible.

Expected: descriptions reflect the logical meaning of interactive elements. For example:

  • Instead of the standard name of the [contemporary jazz] link, it could be aria-label="Open contemporary jazz genre page";
  • Instead of the standard name of the [play] button, it could be aria-label="Play album";
  • Instead of missing the […] button description, it could be aria-label="Open album menu".

Wherefore?

This is 2.4.4 «Link Purpose (In Context)» WCAG requirement (more info).

9. Image Description

Check for alt attribute for images.

Actual result: images do not have alternative text.

9. Image description — <img> tag should have an alt attribute, but it does not
9. Image description — <img> tag should have an alt attribute, but it does not

Expected:

Wherefore? It is necessary to provide a descriptive alternative text for contextual images, so that the users with a screen reader can get an idea of the images or image buttons.

This is 1.1.1 «Non-text Content» WCAG requirement (more info).

10. Color Vision

Check:

Actual result:

  • Non-contrast text. «ALBUM», «Artist», «2020», and «contemporary jazz» are too light — the color contrast between background and text should be great enough to ensure legibility — minimum ratio is 4,5:1 (more info);
10.1. Color vision — color contrast should have a minimum ratio 4,5:1, but it does not
10.1. Color vision — color contrast should have a minimum ratio 4,5:1, but it does not
10.2. Color vision — contrast issue in Firefox Developer Tools
10.2. Color vision — contrast issue in Firefox Developer Tools
  • Hover and active states of the [contemporary jazz] link are not visible in achromatopsia mode.
10.3. Monochromacy or achromatopsia (color blindness), 10.4. Far-sightedness or blurred vision
10.5. Protanopia (absence of red), 10.6. Tritanopia (absence of blue)

Expected:

  • Contrast text;
  • The links are distinguishable from the text;
  • Underlined links (at least when hovered, so that they can be easily distinguished from the normal text).

Wherefore?

This is 1.4.1 «Use of Color» and 1.4.3 «Contrast (Minimum)» WCAG requirements (more info).

11. Resize Text

Zoom page to 200%.

11. Resize text — zoom page to 200 %
11. Resize text — zoom page to 200%

The actual result matches with expected: the layout has adapted to the proportions of the text.

This is 1.4.4 «Resize text» WCAG requirement (more info).

12. Self-check in Lighthouse

Run Accessibility Audit in Chrome Dev Tools.

Look what was missed during manual tests.

12. Self-check in Lighthouse — some of the issues were already covered
12. Self-check in Lighthouse — some of the issues were already covered

If you do not know what to check, then an automatic audit could be started at the beginning of the testing session. Accessibility Inspector in Firefox is usable to identify A11y issues in specific elements.

For further testing, you should start using a screen reader.

References

Similar Articles

Resources

Standards

W3C about ARIA

From MDN

From Google

Tools

Screenreaders

Browser Extensions

Useful Articles

Articles about ARIA

Courses

A11y
Accessibility
Accessibility Testing
Testing
Quality Assurance

--

--

Andrey Enin
Andrey Enin

Written by Andrey Enin

514 Followers
2 Following

Quality assurance engineer: I’m testing web applications, APIs and do automation testing.

No responses yet

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams