LocalGov Drupal Docs
Overview
  • Developers
  • Content designers
  • Designers
  • Contributing
  • Credits System
  • Accessibility
  • Governance
Microsites
Main site
GitHub
Overview
  • Developers
  • Content designers
  • Designers
  • Contributing
  • Credits System
  • Accessibility
  • Governance
Microsites
Main site
GitHub
  • Accessibility
  • Tools
  • Testing methodology
  • Accessibility tests

Accessibility tests

The tests described here are intended to provide a relatively quick, standard process for checking the conformance of LocalGov Drupal. By necessity it covers a sub-set of WCAG success criteria, and wherever possible testers should avail themselves of the full WAI documentation, including the definitive Understanding and Techniques content.

Test annotations:

  • M - Manual
  • A - Automated
  • U - User

1. Resize

TestSuccess criteriaLevelMethod
Resize text [M]1.4.4AAZoom to 200%. Confirm no loss of information or functionality.
Reflow [M]1.4.10AAConfirm no loss of information or functionality, and without scrolling in two dimensions at 320px width equivalent (assuming vertical scrolling content).

For desktop testing, simulate this with Responsive Design Mode in Mozilla or Device Viewport Mode in Chromium browsers.
Text spacing [M]1.4.12AAIncrease:
  • line-height to 1.5x font size
  • Letter spacing to 0.12x font size
  • Word spacing to 0.16x font size
Confirm no loss of content or functionality.

Embed the following CSS snippet for a proximate test:

* {line-height: 1.5em !important; letter-spacing: 0.12em !important; word-spacing: 0.16em !important;}

2. Keyboard

TestSuccess criteriaLevelMethod
Keyboard control for all functionality [M]2.1.1/2.1.3A/AAAIdentify all functionality. Use only the keyboard to access all functions.

Pay particular attention to mouse-centric functionality such as drag-and-drop, scroll, and zoom, and that mouse event handlers such as click have keyboard support.
No keyboard trap [M]2.1.2ANavigate through the entire content using the keyboard. Ensure focus is not trapped in any element. Pay particular attention to embedded elements such as video and maps.
Visible focus [M]2.4.7AANavgiate the content using the keyboard. Ensure that any elements that accept focus have a clear focus indicator, and that only one element displays a focus indicator at any given time.

See 2.4.11 for guidance on clearly visible indicators.
Links to skip blocks where appropriate [M]2.4.1AIdentify blocks which may benefit from skip links. For example a list of recent news items, or navigation blocks. Ensure that there is a link to skip these blocks.

As a minimum, the first focusable element on all pages should be a link to skip to the main page content.
Focus order [M]2.4.3ANavigate the content using only the keyboard. You should encounter information in an order that is consistent with the meaning and structure of the content.

Pay particular attention to elements where the tabindex attribute may have defined, multi-level navigation in menus, interfaces which hide and reveal content based on user input, forms, and modals.

See also SC 1.3.2 - Meaningful sequence
No change of context on focus [M]3.2.1AEnsure that when an element receives focus, there is no context change including:
  • focus moving to another element;
  • submission of a form automatically;
  • opening of a new window.
In short, check that when the user navigates to an element and it receives focus, the focus remains there until the user moves it.
Change of context on input [M]3.2.2ACheck that entering data or selecting a form control has predictable effects. Where a potentially unpredictable effect will occur, such as focus moving to another form element on input, describe the effect to the user at the beginning of the form or as part of the element label.

For example, a form control for a credit card may consist of four separate text inputs, with focus moving to the next as soon as the user enters 4 digits in the previous input.

This behaviour should be described to the user before the form control (although in this case the potential user benefit to the behaviour is questionable at best).

3. Colour, contrast, animation

Most automated tools including pa11y and FAE will check and report on colour contrast, but may not always correctly identify text sizes or test focus indicators and other non-text contrast.

For testing a single page, use the built-in browser accessibility tools which have excellent colour contrast coverage: Accessibility Inspector (Mozilla) or Lighthouse (Chromium).

Manually test any components that have state changes triggered with javascript, for example accordions.

When testing specific colour values during development, use an application like Colour Contrast Analyser, a browser extension, or WebAIM's web-based contrast checker.

TestSuccess criteriaLevelMethod
Colour contrast - regular text [M,A]1.4.3/1.4.6AA/AAACheck that contrast ratio for regular text (under 18pt, or 14pt if bold) is at least 4.5:1 (AA) or 7:1 (AAA) using the W3C's contrast ratio definition.
Colour contrast - large text [M,A]1.4.3/1.4.6AA/AAACheck that contrast ratio for large text (at least 18pt, or 14pt if bold) is at least 3:1 (AA) or 4.5:1 (AAA) using the W3C's contrast ratio definition.
Colour contrast - focus indicator [M]1.4.11AA/AAAEnsure the contrast ratio between any focus indicator and its background is at least 4.5:1 (AA) or 7:1 (AAA).
Contrast for graphical objects [M]1.4.11AA/AAAWhere an graphical object is used to convey meaning to a user that is not communicated by other means, ensure the object has sufficient contrast in itself and against its background.

For example, an icon of a telephone with a telephone number beside it must have sufficient contrast, unless the word 'Telephone number' or other meaningful label is also provided.

This is a complex issue - review the WAI Understanding documentation for more information.
Colour contrast for selection [M,A]1.4.3/1.4.6AA/AAAThe CSS pseudo-element ::selection allows designers to style text which is selected. Ensure that selected text meets the minimum contrast ratio as per regular and large text above. (Use Cmd / Ctrl A to select all text in the selected browser window.)
High-contrast modes1.4.3AACheck that colour choices do not conflict with default settings for Windows High Contrast Mode and other OS / browser dark modes. This can be a cursory check - it is not possible to account for all user-defined preferences.
Meaning is not conveyed through colour alone1.4.1ACheck that colour is not the sole method of communicating information or state. This includes but is not limited to:
  • links, which should be underlined or have some other visual indicator when in body text;
  • indicators for required fields and errors in forms;
  • disabled content and elements;
  • active/non-active tabs or other interface elements.

4. Links & buttons

To extract a list of all links on a page, along with their link text, try URL Extractor. NB: This doesn't reliably determine link text / titles, especially when anchor elements surround multiple child elements such as an image + text.

(The Web Developer Toolbar browser extension used to provide this information, but recent versions only tabulate URLs without link text.)

TestSuccess criteriaLevelMethod
Link purpose [M,A]2.4.4/2.4.9A/AAACheck that the purpose of each link on the page can be determined from the link text alone, or the link with its context (for example a link in a table cell may have context provided by a table header cell). Where links span multiple elements, for example an icon and text, ensure the text equivalents for non-text content make sense in combination with the link text. In most cases a null alt attribute for images.

Where the link is to a downloadable resource, include the file size in the link text. This provides users with information that helps them to make a decision about whether to download the resource.

Where multiple versions of a resource are linked to, for example PDF and Word versions of a downloadable document, use consistent link text for the subject and distinguish the links with the format, for example 'Title of document (PDF 1MB)'.
Link text unique across destinations [M,A]2.4.4ACheck that link text is unique across link destinations. Automated tests can help with this. If links have the same destination, using the same text for them all is recommended (commonly found for things like contact links in a site header and footer).
Use the button element for buttons [M]2.4.4AButton and link elements behave differently in browsers, so use them for their intended purposes. Both are focusable, but buttons are triggered by either the space bar or the Enter key, while links are triggered by the Enter key. If a button is no focussed, the space bar will scroll the current window by a page. This is why you should rarely style links to look like buttons - a user pressing space bar may expect an action to be performed, but will instead have their viewport scrolled downwards.

Links will be listed by most screen readers in a specific interface for users to browse available navigation options, buttons will not be.

When triggered, links should take the user to a new destination or a section within the current page. Buttons should perform an action such as submitting a form, closing or opening a section of content, or something similar. This is an issue to be particulary conscious of with interfaces enchanced with javascript.
Link target size [M]2.5.5AAAEnsure touch targets have a size of at least 44 x 44 CSS pixels. Inline links and links with equivalent targets of sufficient size are not required to meet this minimum, but it is good practice nonetheless.

5. Images

TestSuccess criteriaLevelMethod
All images have alt attributes [A]1.1.1ATest with an automated tool.
Populated image alt attributes are appropriate [M]1.1.1ACheck that all images have appropriate alt attributes - null for decorative images, and communicating the purpose of the image otherwise.

Web Developer Toolbar > Images > Display Alt Attributes shows alt attributes inline on a page.

Outline Images Without Alt Attributes from the same menu highlights images without alt attributes.

(View Image Information from the same menu provides a table of all images used on a page, but includes background images, and does not register null alt attributes.)

If in doubt, use the WAI alt Decision Tree.
Decorative images have a null alt attribute and no title attribute [M]1.1.1ANB: Although it's also acceptable to use the role="decorative" attribute instead of an alt attribute, there's no good reason for doing so.
Use text instead of an image of text unless particular presentation of the text is required1.4.5/1.4.9AA/AAACheck for images of text used for headings and other purposes where styled text would achieve the same effect. This ensures users can resize and otherwise manipulate the content to their preference.

This does not apply where the image contains other significant content, or where the text requires a particular presentation to convey its purpose, for example a logo.
Images of text have an alt attribute of the text in image unless the text is purely decorative [M]1.1.1AWhere an image is primarily a representation of text, for example a logo or sign, ensure the alt attribute matches the text in the image, or is null if the image is purely decorative.
aria-label attributes are used appropriately [M]1.1.1Aaria-label can be used alongside the ARIA role role="img" to identify multiple elements as a single image. For example 3 images within a <div> can be given null alt attributes, and the containing <div> an aria-label that describes the composite image. (aria-labelledby could also be used in this case if the text alternative was defined elsewhere, for example in a heading.)

6. Video & audio

TestSuccess criteriaLevelMethod
A text alternative serving an equivalent purpose should be provided for pre-recorded video and audio [M]1.1.1/ 1.2A-AAAProvide transcript for audio-only, audio-description for video-only.

For synchronised media (audio and video) provide synchronised captions, and to achieve AAA provide sign language interpretation.

For live video and audio, only provide a descriptive label.
Audio does not autoplay [M]1.4.2ADo not automatically play any sound that last more than 3 seconds. Best-practice is to not auto-play any audio.
Media can be controlled with the keyboard [M]2.1.1ACheck that all media can be controlled with the keyboard, and can at least be paused with the space bar when focussed.
Assess seizure risk of video [M]2.3.1AReview video for flashes and blinks that may trigger photosensitive seizures.

7. Forms

The Web Developer Toolbar provides several useful tools for viewing and testing forms:

  • Display Form Details will show form element markup inline;
  • Outline Form Fields Without Labels does exactly what you'd think;
  • Remove Form Validation is useful for submitting incomplete forms which have client-side validation;
  • View Form Information provides a tabular view of all form elements including their type and label.

TestSuccess criteriaLevelMethod
Form instructions [M]3.3.2AProvide general instructions to help users understand how to complete the form. These should be provided before the <form> element.
Labels [A,M]1.3.1/3.3.2AEnsure all form controls have explicitly associated <label> elements that clearly and unambiguously describe the form control's purpose.

If using the aria-labelledby attribute on the form control element, be aware that it is used instead of the <label> by screen readers.

aria-labelledby can also support multiple values - be aware that the order the values are declared determines the reading order.

Use aria-describedby to provide information additional to that in the <label> - it is announced in addition, not instead of the <label>
Label visibility [M]--If a label is hidden, use a technique that still makes it accessible to ATs.
Required information [M]1.3.5AAUse aria-required or required attribute on required elements. The latter is preferred since it provides client-side validation in most browsers and is announced by most screen readers.

Labels for required fields should also contain the word 'required' - do not rely on colour alone to indicate required fields. An asterisk is less accessible, due to variations in screen reader handling, but acceptable if one of the required attributes is also used.
Autocomplete / input purposes1.3.5AAUse the autocomplete attribute when appropriate to assist users, for example autocomplete="name" - see the list of Input Purposes for User Interface Components for full scope
Group related fields [M]1.3.13.3.2AGroup related inputs with either a <fieldset> and <legend>, or with ARIA group roles and labels.

Radio buttons should always be grouped with a <fieldset>.

When using ARIA group roles, set the role="group" attribute on the containing element, and use the aria-labelledby attribute to set the label for the group.
Multi-select controls [A]2.1.1AAvoid using multi-select controls where possible, unless supported by a javascript or other library that improves their keyboard navigation. (Multiple checkboxes can provide a direct alternative.)
Validation [M]3.3A-AAAUse HTML5 input type attributes to support client-side validation and help users to not submit incomplete or invalid information.
Error notification [M]3.3.1/3.3.3A/AAAIf the user submits a form that results in an error or errors, notify the user.

At a high-level, this should be done via the main heading of the page, generally an <h1> or <h2> elements, and optionally the <title> element. This ensures the failure of the form submission is communicated clearly to all users, and announced by screen readers in a prominent element.

Ideally, all errors should be enumerated and listed at the top of the form page in a container with role="alert", and linked to the relevant form control. Inline feedback should be included within or near each form control that requires the user's attention. This should not be based on colour or graphical indicator alone, and the control labels and descriptions should provide clear indication of an error, and assistance to the user in how to correct it. aria-describedby is ideal for providing additional contextual feedback for users (see Labels above).

If providing error notification as a user inputs data, for example if an invalid character is used in a field, ensure the notification container has the aria-live attribute set with the value polite (source). If notification is triggered on focus change, i.e. when focus leaves the form control, set aria-live to assertive (source).

8. Non-HTML documents

  • If possible don't use non-HTML formats, or provide HTML alternatives.
  • Observe best accessibility practices for the document format: PDF, MS Word, MS Excel, MS Powerpoint

9. Tables

TestSuccess criteriaLevelMethod
Use for tabular data only [M]1.3.1AUse the <table> element for tabular data only. Do not ever use it for layout, even if WCAG says you can. If you need a grid layout, use CSS Grid.
Captions [M]2.4.6AAAll tables should have a <caption> element as their first child. For complex tables that need a lengthy description, consider adding a <span> within the <caption>, or use an element before or after the <table> and associate it using aria-labelledby on the <table> element. (The <table> summary attribute can also be used, but is not rendered by browsers and generally only available to screen readers.)
thead, tbody, tfoot [M]1.3.1AEnsure structural elements within the table are used appropriately.
th scope defined [A]1.3.1ASet the scope attribute for all <th> elements, even if there are only uni-directional table headers, since some screen readers may not determine the correct scope.
headers attribute [M]1.3.1AFor complex tables with multiple or nested headers, use the <th> headers attribute to define the cell header, where the value matches the id of the <th> containing the label. headers accepts multiple values, screen readers will read the corresponding values in the order in which they are declared in the attribute.

10. Semantic, valid HTML

TestSuccess criteriaLevelMethod
Valid HTML [A]4.1.1AValidate the HTML of the page. See HTML Validation for details.
ARIA landmarks [A]4.1.2AUse ARIA landmarks to identify the regions of the page and help users navigate around it.

Do not define the role attribute for HTML5 elements that have implicit roles: see List of implicit ARIA semantics.
All content in landmark region [A]1.3.1AEnsure all content resides in a landmark region.
Consistent, contiguous headings [A,M]1.3.1/2.4.6A/AAHeading elements should be consistent across a site and site sections. Heading ranks (levels) should be contiguous when increasing the heading level, but can skip levels when decreasing (e.g. <h4> followed by <h2> is acceptable).

There is an exception for fixed page sections, such as sidebars, which do not have to maintain rank flow from other content areas (source).
Linear content flow [M]1.3.2AContent should be ordered in a meaningful sequence, when linearised. For example multi-column content should flow from the top to the bottom of each column, before moving to the top of the next column.
Use of most suitable elements [M]1.3.1ACheck that the most suitable semantic elements are used for all content and controls. Common opportunities for improvement are:
  • ordered, unordered, and definition lists;
  • <a> elements used as buttons, especially with javascript in UI controls;
  • abbreviations/initialisms not using <abbr>.

11. Document titles

TestSuccess criteriaLevelMethod
Unique across site [A]2.4.2ACheck that all page titles are unique across a site. Most easily done with a crawler and post-crawl analysis.
Page titles reflect content [M]2.4.2ACheck that page titles are meaningful and reflect the page content.

12. Screen reader

TestSuccess criteriaLevelMethod
Communicate important state changes [M]4.1.3ACommunicate important state changes to users of AT by setting the aria-live attribute or role="alert" on the message container. Use the latter where there is no change of context.
ARIA widget attributes [M][4.1.2]ADefine appropriate aria attributes for interface elements. For example aria-expanded for accordion controls. See the list of valid attributes for reference.

13. Content

TestSuccess criteriaLevelMethod
Default human language [AA]3.1.2ACheck the HTML element has the lang attribute set.
Unusual words3.1.3AAAMinimise jargon, provide explanations for specialist language.
Abbreviations+ [M]3.1.4AAAUse appropriate HTML to define abbreviations, initialisms, and acronyms. Always expand abbreviations+ on first use.
Use plain language3.1.5AAAContent should be written as clearly and simply as possible.

14. Progressive enhancement

  • Whenever possible, build robust and resilient pages that function if CSS and/or javascript are not available or fully functional.
  • Create a baseline experience using HTML and CSS that provides access to the information the page is communicating.
  • Use feature detection to check browser supports.
  • Inject javascript-dependent features using javascript.
Help us improve this page!
Last Updated:
Prev
Testing methodology