Accessibility assurance report for Compare school and college performance (CSCP)

All new public sector websites and systems are required to meet accessibility standards and publish an accessibility statement to make clear the level of accessibility1. Where there are barriers, the statement should inform users of alternative routes to access and also enable users to contact the website owner if they identify issues.

When fixing issues, the key acceptance criteria of the European or international standards (respectively, EN 301 5491 and WCAG 2.1 AA) need to be met. There are a number of things that an IT project team can do to mitigate these risks:

  • Accept responsibility for the accessibility agenda. The Senior Responsible Owner should ensure that their IT project is compliant and accessible.
  • Allocate appropriate resource to ensure accessibility is addressed throughout the project. Accessibility should not be viewed as out of scope or an add-on.
  • Engage with customers and appropriate colleagues to ensure and verify compliance. Business processes, job roles and the whole system environment must be taken into account and the project must actively seek advice and guidance on accessibility from appropriate sources. This could mean involving staff in development activities, setting up focus groups, or consulting others.
  • Understand the implications of systems not being accessible. There is always an accessibility requirement and impact on users is relevant to the end outcome of a project, whether that impact is positive, negative or neutral.
  • Document all decisions made by the project relating to accessibility. and present them to stakeholders and assurance managers at appropriate stages.
  • Pro-actively manage risks and put actions in place to mitigate actions. In some cases, these may turn into "restrictions" when the system goes live, but plans should already be in place to make improvements.
  • Continue to accept ownership for the system, even after rollout. Any problems that prevent users from accessing parts or all of the system should be rectified. Likewise, any future releases, updates or patches should be tested for accessibility before rollout.

About the Testing

Testing was carried out using the following software:

  • Dragon NaturallySpeaking (V15.4) is a voice recognition (speech to text) program used by people who may have upper limb disorders or specific problems using their hands. It requires minimal user interface from a mouse or keyboard.
  • JAWS (2020) is a screen reader (text to speech) program developed for users whose vision loss prevents them from seeing screen content or navigating with a mouse. JAWS provides speech and Braille output for the most popular computer applications.
  • Zoomtext (2020) is a fully integrated magnification and reading program tailored for low-vision users. It enlarges and enhances everything on screen, echoes typing and essential program activity, and reads screen content.
  • Fusion (2020) is a hybrid of ZoomText with its screen magnification and visual enhancements, coupled with the power and speed of JAWS for screen reading functionality.

At the time of testing, these were the Department’s supported versions of accessibility software.

Things to note

  • Relevant and applicable WCAG 2.1 AA standards were considered and reported against where these were not met. These are detailed in Annex 1.
  • The browser used was IE11 as this is standard in the Department.
  • Testing was undertaken with 2 different screen reader packages as they often interact differently with a page.
  • Testing was carried out using only keyboard/keyboard commands and voice where applicable. A mouse or similar device was not used.
  • During testing, consideration was given to usability and to neurodiversity.
  • Compatibility/usability cannot be guaranteed for people who access the system outside of the DfE network as it is impossible to test for every browser, operating system and accessibility software package.

General Comments

The information is laid out in a structured way. The “skip to main content” link and use of headers to display text aids navigation. Navigation would be improved by the inclusion of more “home” or “back” buttons.

All the form elements are correctly labelled so are easily identifiable. Information in tables is clear and well set out.

Dragon Naturally Speaking

General Observations

On the whole, the system responded to standard Dragon voice commands and it was easy to navigate.

Specific Issues

There are some radio buttons that don’t respond to standard voice commands. These can be found on the left hand side of the page and are used to filter information that has been searched for.

Actions to Take

  • Review the radio buttons used to filter information and verify that these are standard HTML coded elements.

JAWS and FUSION

General Observations

The information is laid out in a structured way. The “skip to main content” link and use of headers to display text aids navigation.

All the form elements are correctly labelled so are easily identifiable. Information in tables is clear and well set out.

Actions to Take

  • None.

Zoomtext

General Observations

The information is laid out in a structured way. The “skip to main content” link and use of headers to display text aids navigation.

All the form elements are correctly labelled so are easily identifiable. Information in tables is clear and well set out.

Actions to Take

  • None.

Overall Findings and Recommendations

In its current form, the system is sufficiently accessible to users of assistive technology and as such no further work should be done before it is rolled out.

JANE DICKINSON
IT Accessibility Advisor

Technology Services: End User Computing
Technology Directorate

2nd April 2020

Annex 1: Web Content Accessibility Guidelines 2.1

WCAG 2.1 is based on 4 design principles:

  • perceivable
  • operable
  • understandable
  • robust

By focusing on principles, not technology, they emphasise the need to think about the different ways that people interact with content. For example, users might:

  • use a keyboard instead of a mouse
  • change browser settings to make content easier to read
  • use a screen reader to ‘read’ (speak) content out loud
  • use a screen magnifier to enlarge part or all of a screen
  • use voice commands to navigate a website

The principles apply to all aspects of a service (including code, content and interactions), which means all members of a team need to understand and consider them.

Provide text alternatives for non-text content (e.g. images)

1.1.1 - Provide text alternatives for non-text content (e.g. images)

Provide alternatives for time-based media (audio and video)

1.2.1 - Provide alternatives for pre-recorded audio-only/video-only content
1.2.3 - Provide alternatives for pre-recorded synchronized audio/video
1.2.4 - Provide captions for live audio in synchronized audio/video

Content can be presented in different ways (e.g. through a screen reader) without losing info or structure

1.3.1 - Information, structure, and relationships can be programmatically determined
1.3.2 - The correct reading sequence can be programmatically determined
1.3.3 - Do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound
1.3.4 - Do not restrict a page’s view to a single display orientation, such as portrait or landscape, unless a specific orientation is essential.
1.3.5 - For text input elements, the autocomplete attribute should be in place to let the user know what kind of data is expected to be entered.

Make sure content is readable and the foreground contrasts sufficiently with the background

1.4.1 - Colour is not used as the only visual means of conveying info
1.4.2 - Audio can be paused and stopped, or the audio volume can be changed
1.4.3 - Text has enough contrast with the background (contrast ratio 4:5:1 for small text and 3:1 for large text)
1.4.4 - Text can be enlarged up to 200% without the use of assistive technology (screen magnifiers)
1.4.5 - Text is used rather than images of text, except where the presentation of text is essential, such as in logos
1.4.10 - When content is zoomed in to a large degree, the site will adapt to ensure that scrolling only occurs in one direction.
1.4.11 - Visual objects must have a contrast ratio of 3:1 against adjacent color(s).
1.4.12 - Text-based CSS settings can be changed to certain minimum values without loss of content or functionality.
1.4.13 - Content that appears on mouse hover or keyboard focus must be dismissable, hoverable, and persistent.

Make all functionality available from a keyboard

2.1.1 - All functionality is available from a keyboard, except for tasks such as drawing
2.1.2 - The user can use the keyboard to move through page elements and is not trapped on a particular element
2.1.4 - If single character key shortcuts are used, then they can either be turned off, remapped, or are only active when the shortcut for a UI component has focus.

Give users enough time to read and use content

2.2.1 - Users are warned of time limits shorter than 20 hours and time limits can be turned off or extended
2.2.2 - Users can stop, pause or hide moving, blinking, scrolling or auto-updating information

Do not use content that can cause seizures

2.3.1 - No more than three flashes in a 1- second period, or the flashes are below the defined thresholds

Help users to navigate, find content, and determine where they are

2.4.1 - Users can bypass blocks of content that are repeated on multiple Web pages, such as navigation menus
2.4.2 - The page has a title describing its topic or purpose
2.4.3 - Users can tab through the elements of a page in a logical order
2.4.4 The purpose of each link can be determined from the link text or context
2.4.5 - More than one way is available to navigate to other Web pages, such as a sitemap
2.4.6 - The headings and labels are clear and consistent, accurately describing the topic or purpose
2.4.7 - The page element with the current keyboard focus has a visible focus indicator

Make it easier for users to operate functionality through various inputs beyond keyboard

2.5.1 - All operations must use simple gestures that need only a single touch or click. If more complex operations exist, a single touch or click alternative must be given.
2.5.2 - Allow users to recover from accidental or erroneous pointer input (touch screen taps, mouse clicks)
2.5.3 - For user interface components with visible text, ensure that the accessible name includes the visible text.
2.5.4 - Motion input (shaking, orientation change, tilting, etc.) must be accompanied by another means of input (such as a button)

Text should be readable and understandable

3.1.1 - Specify the language (e.g. English) of the Web page
3.1.1 - Specify the language (e.g. English) of the Web page
3.1.2 - Specify the language (e.g. English) of each text phrase or passage that is in a language other than the default language specified for the entire Web page

Make Web pages appear and operate in predictable way

3.2.1 - When a UI component receives focus, this does not trigger unexpected actions such as automatically submitting a form, opening a new window or switching focus to another element
3.2.2 - Changing the setting of a checkbox, radio button or other UI component does not trigger unexpected changes in context, such as causing significant changes to the page content or opening a new window
3.2.3 - Navigation menus are in the same location and order on every Web page
3.2.4 - UI components used across the Web site are identified consistently on every page

Help users to avoid and correct mistakes

3.3.1 - Input errors are clearly marked and described to the user
3.3.2 - Items requiring user input are clearly labelled or have clear instructions
3.3.3 - When the user makes an input error, give suggestions for valid input
3.3.4 - For Web pages causes legal or financial commitments, input can be reviewed and corrected before final submission, and submissions can be reverted

Maximize compatibility with assistive technologies (such as screen readers) and future browsers

4.1.1 - Use valid, error-free HTML, including unique (non-duplicate) element IDs
4.1.2 - For all UI components, the name, value and role can be programmatically determined
4.1.3 - Status Messages must be available to AT such as screen readers. This does not include context changes (e.g. alert or dialogs)

1Anything published since September 2018 will need a statement by September 2019, while older websites have until September 2020 to comply. A link in the header or footer is sufficient.