Introduction
It is Foster Moore’s objective to develop the Verne product in a way that meets the success criteria of the level A and level AA accessibility guidelines of WCAG2.1.
Because Verne is a configuration driven product, it is possible to configure services within Verne that do not meet these success criteria. As a simple example, if a configurator assigns alternative text to an image that identifies the image as an elephant, and the image is not in actual fact an elephant, then the service that the image features in does not meet the success criteria for the level A guideline 1.1.1 – Non Text Content.
In order to develop the product in a manner that meets the success criteria, a development and testing strategy has been put in place to achieve this. However, to fully understand the strategy, it is important to appreciate some of the development and architectural design principles that Verne encapsulates.
Accessible Design System
A Design System is a complete set of design standards, documentation and principles, along with the toolkit (UI patterns and components) that are defined to achieve those standards. In order to implement an accessible solution, all aspects of the Design System must be established with accessibility in mind, and tested in isolation to ensure that they meet the level A and level AA success criteria.
Pattern Library
A Pattern Library is a subclass of the design system, and contains the set of User Interface patterns for use within Verne. These patterns are often interactive, and are designed to meet the level A and level AA success criteria for accessibility, and to also incorporate best practices for usability (sometimes also known as inclusive design), while not compromising the accessibility success criteria.
Style Guide
A Style Guide is also a subclass of the design system, and it comprises static documentation that describes the design system itself: how the standard Verne product looks and feels, use cases for UI patterns, correct typographic scales, etc.
User Interface Components
The user interface components represent the combination of the pattern library content with specific HTML constructs. These establish consistent, embedded user interface components that are used within Verne to render the services to the end user. By ensuring that the pattern library, style guide and UI components all meet the success criteria for the level A and AA guidelines, it ensures that the standard and templated product services within Verne are generated to meet the same success criteria.
Design System Testing
As stated, all aspects of the Design System, including the developed User Interface components must meet the success criteria of the level A and level AA guidelines for accessibility. In doing so this enables Foster Moore to issue a Verne Accessibility Conformance Report, using the Voluntary Product Assessment Template (VPAT®) with respect to the Design System Components, and to establish a foundation for testing a bespoke configured project or implementation with respect to accessibility conformance.
Component Criteria Test Matrix
In order to perform the testing, a testing matrix is established, where each applicable level A and level AA guideline success criterion is referenced against every component of the Design Library. Depending on the nature of the component and the test criterion, a test is carried out using a series of test methods, detailed later.
Design System Subclasses
The following subclasses exist within the Verne Design System: –
Styles
The styles subclass contains all of the standard User Interface colours, typography, grid system, and other visual aspects within Verne.
UI Components
The component subclass contains all of the discrete, autonomous user interface components that are embedded within Verne and complement the configuration that defines the functionality of the services.
UI Patterns
The UI patterns subclass contains logical collections of user interface components that form a cohesive and standard user experience in a business and usability context.
Configuration
The configuration subclass contains configuration constructs such as widgets and specific components, along with specific instruction on how a configurator can leverage them.
Accessibility Testing Tools and Methods
Testing Tools
The following tools are used to perform design system testing: –
aXe
aXe is an automated and guided accessibility testing tool for component developers, front-end developers, native mobile app developers and test engineers that typically can find 76-84% of accessibility errors before an application get out of development. Unit testing, test automation, and integration with testing frameworks such as Selenium and QUnit, combined with in-browser testing enables the incorporation of accessibility testing into the development and testing environments.
WAVE
WAVE is a suite of evaluation tools to support greater accessibility in web content. WAVE can identify many accessibility and Web Content Accessibility Guideline (WCAG) errors, but also facilitates human evaluation of web content.
Screen Readers
Screen readers are assistive technology that render text and image content as speech or braille output. Screen readers are essential to people who are blind, and are useful to people who are visually impaired, illiterate, or have a learning disability. There are a number of different screen readers in the accessibility environment, each offering similar, yet slightly differing services and functionality to a user. Foster Moore use the following screen readers to test accessibility issues, based on the coverage of the market that they provide.
- JAWS (Job Access With Speech) – Used with Microsoft Windows, and supporting Vista onwards, JAWS is the second most popular screen reader based on the WebAIM 2019 survey, with 40.1% of the survey using it as their primary screen reader.
- VoiceOver – Used with Apple operating systems MacOS, iOS, tvOS, watchOS and iPod.
- NVDA (NonVisual Desktop Access) – Used with Windows, NVDA is a free, open source screen reader that also offers support for Chrome and Firefox. It is the most popular screen reader based on the WenAIM 2019 survey, with 40.6% of the survey using it as their primary screen reader.
Browsers
Similarly to screen readers, browsers offer differing support for accessibility. Foster Moore test and support accessibility in Verne under the following browsers.
- Chrome
- Firefox
- Safari
- Edge Legacy
- Edge Chrome
- IE 11.
Recommended Combinations
Some screen readers support multiple browsers to some degree, but all screen readers work best when paired with their favoured browser. For example, using JAWS with Edge will work for some things, but it will not be as robust an experience as using JAWS with Chrome and will not be as accurate of an accessibility test.
Based on the functionality of the screen reader and the browser, Foster Moore recommend that the following combinations be used to achieve the most comprehensive test coverage: –
| Browser | Recommended Screen Reader |
|---|---|
| Chrome | NVDA or JAWS |
| Firefox | NVDA |
| Edge | NVDA or JAWS |
| Safari | VoiceOver |
| Chrome (Android) | TalkBack |
| Internet Explorer | JAWS |
Manual Testing
As stated, automated testing does not cover all areas where web content does not meet the success criteria. Foster Moore undertake manual testing of Verne, and uses the following checklist: –
| Checklist Item | Description |
|---|---|
| Automated Testing | Was the code checked with aXe and WAVE? |
| Semantics and Structure | Can structure, information and relationships conveyed through visual presentation (in headings, lists, menus, forms, etc.), be programmatically determined? |
| Readability | Has the reading order been tested to confirm that all content on the page is available in a logical order for assistive technologies? |
| Images | Do all linked, informative, and decorative <img> elements have appropriate alternative text (e.g., alt attributes)? Do all informative background images have alternative text on the page that can be read by assistive technologies? |
| Keyboard and Touchscreen Navigation | When interacting with a page with the keyboard, is focus always visible, is it managed when necessary, and does it follow a logical order? Can all functionality be accomplished using only the keyboard? Do all keyboard-only (and touchscreen) interactions follow expected patterns so users know how to interact with all widgets on the page? Can keyboard-only users always move focus without ever getting trapped? |
| Tables | Are data tables marked up to convey the correct relationships between data cells and their associated column or row header cells? |
| Form Labels | Do form controls have visible labels? Are the label and control programmatically associated? Are related fields grouped and associated with a common label (if present)? |
| Form Errors | Are error descriptions programmatically associated with their form element? If an error is detected on form submission, are screen reader users made aware of it? If a validation error occurs during user input or when a user moves focus, is the error message spoken by a screen reader? |
| Custom Controls | Do all custom controls, scripted components and widgets provide names and roles to mimic native HTML controls and are they programmatically determinable? |
| Context Changes | Has it been verified that when an element receives focus, for example by tabbing to it, no major change of context is automatically triggered? Has it been verified that when a person changes the setting of a user interface component, no major change of context is automatically triggered unless they have been notified beforehand? |
| Timing | For scrolling, moving, blinking, dynamic or auto-updating content are mechanisms provided to stop, pause, hide, and control it? Can the time limit for completing a task be turned off, adjusted, or extended by the user — unless an exception applies? |
Exceptions
There are instances where differences in the combination of screen reader and browser provides differing results, or certain success criteria cannot be supported. While Foster Moore make every effort to address these exceptions, it reserves the right to advise of instances where the combination of a browser and a screen reader leads to a success criterion not being met.
Other Verne Material
In addition to the Verne software, all documentation, be it HTML, Word or PDF will be tested for accessibility.
Implementation Testing
As stated previously, the Verne product provides accessibility compliant components and template services that can then be introduced and amended to suit a particular implementation. Often the basic behaviour of the services and components can change, based on the particular requirements. To this end, the same set of testing disciplines is applied to an implementation.
