Performing a Manual Audit

This section details how to tackle an audit. It assumes a good existing knowledge of the WCAG 2.1 criterion and how their techniques can be applied on a website. For each page or user journey within the scope of an audit, the process below can be applied to check for accessibility issues.

A page can be split into two distinct parts – the structure of the website itself (e.g. navigation, styling and the website’s markup language) and the content on the page (e.g. text, images and things that are different on each page).

A step-by-step breakdown of how to audit can be found on Microsoft’s Accessibility Insights for Web Extension by clicking the ‘Assessment’ button, but the following method is a more natural and efficient way of covering the audit checks.

Tools Required

  • Screen Reader – NVDA, VoiceOver/TalkBack (mobile)
  • Magnifier – Windows Magnifier/ZoomText/OS X Magnifier
  • Automated Tools – Microsoft Accessibility Insights & Axe Other Tools – W3 Validator, WebAim Contrast Checker

Markup

Firstly, inspect the HTML of the page to determine if there are any accessibility issues. These could include:

  • Tags not closed/complete
  • Styling in HTML rather than CSS
  • Elements not having the correct labels and attributes (e.g. forms have labels linked to them)
  • ARIA labels assigned correctly
  • Page language not declared or elements with a different language are not defined
  • Parsing errors – use W3 Validator to check this
  • Semantic HTML not used appropriately (e.g. tables for whitespace/layout). kent.gov.uk

Keyboard and Screen Reader

Reload the page, then run through the page from top to bottom using only keyboard keys (Shift, Shift+Tab, Arrow Keys, Enter and ESC) with a screen reader running. This test will identify most issues with content and navigating around the website. Things to look out for:

  • The page and all its elements should be fully navigable and usable with a keyboard only
  • The user should not get trapped within an element when using a keyboard-only
  • The first element should be a button to skip the navigation called a “skip to content” button
  • Images are defined to the screen reader
    • If decorative, the alt text should = “”, or the image is implemented using CSS and the screen reader skips it
    • Else the alt text should adequately describe the image
    • For complex images, the alternative can be a text description elsewhere on the page so long as this is clear
  • Images do not contain text unless essential (e.g. name badges within the image)
    • Branding text and logos are classed as essential
    • SVGs are also fine as they allow text in the image to be customised and controlled with assistive technologies
  • Text is read by the screen reader
  • Links are clear and descriptive in context
    • ‘Read more’ or ‘click here for example’ links are not suitable
  • Keyboard focus is highlighted in a colour that meets contrast requirement against other elements
  • Contrast of text is above 4.5:1 and non-text elements are above 3:1. Check this using the WebAIM Contrast Checker
  • Content does not rely on sensory characteristics, including colour not used as the method of conveying content/distinguishing visual elements
  • When additional content is presented when an element is focused on, the content should be focused on and escapable
  • When information is inputted, the page should not substantially change/disorient the user
  • · Ensure that the keyboard journey follows a logical sequence (e.g. navigation tabs through in order) and elements that are linked follow similar sequences.

No Styles

The web page should then be checked again using the keyboard-only and with a screen reader but this time with the CSS styling removed. This check should be done in Internet Explorer by going to ‘View’ > ‘Style’ > ‘No Style’. This check can be done in Chrome, but it requires stylesheets to be manually deleted in Inspect Element which is a lot more difficult than the dedicated IE button.

You should check that:

  • Reading and navigation order are logical and intuitive
  • Core functionality of elements still works
  • Page is still fully navigable with the keyboard
  • No artefacts that could disorientate the user appear.

Additional Checks

Finally, the following should be checked if appropriate (e.g. they appear on the page in question).

Automated Tests

After a manual audit, use an automated tool to confirm your findings and pick up on things you may have missed. Tools such as Axe will analyse a page to produce a report on the structural errors it has found. These tools will only pick up structural errors however, which only covers off 20-30% of WCAG guidance.

Forms

Check forms on the website to ensure that:

  • Labels match and are descriptive
  • Form elements are keyboard navigable
  • Form elements are screen reader compatible
  • Form elements have accessible names
  • If the user can change or delete legal, financial or test data, these changes/deletions can be reversed, verified or confirmed
  • Order of form elements is logical
  • Errors identified appropriately and fixes suggested.

Multimedia

Videos should be checked that they:

  • Can be fully controlled with a keyboard only
  • Do not play automatically
  • Provide synchronised closed captions
  • Provide text transcripts
  • Provide audio descriptions if information is provided in the video visually but not audibly displayed (e.g. by narrator).
  • Audio elements should be checked that they:
  • Have controls to stop, pause, mute or adjust volume, and that these controls are keyboard accessible
  • Do not play automatically
  • Any information is conveyed in an alternative format.

Carousels should ensure that:

  • Images meet accessibility requirements
  • All functionality can be controlled with a keyboard
  • Mechanisms are present for the user to pause, stop and hide the carousel.

Other multimedia-based checks:

  • No page content should flash more than 3 times per second
  • Functionality triggered by moving the device can be disabled and equivalent functionality is provided via standard controls like buttons.

Documents

A subset of non-exempt documents hosted on the website should be tested for accessibility. For a detailed breakdown of what to check for documents, see the Document and PDF Guide. kent.gov.uk

  • If a Microsoft document, ensure that the ‘Accessibility Checker’ says there are no accessibility issues
    • Some warnings may need your judgement. For example, assessing table structure will be a case of tabbing through with a screen reader to ensure that the order is logical.
    • You will still need to do the following manual checks that the checker cannot do:
      • Information not conveyed using colour alone or that relies on one sense
      • Link purpose is clear and descriptive
      • Alt text is appropriate
      • Images do not contain text
      • Headings are set using ‘Styles’ and are therefore collapsible and show up in navigation
      • Videos and audio can be controlled and have the relevant alternative formats (e.g. captions and audio descriptions on videos).
  • If a PDF, ensure that:
    • PDF is a PDF/A – this is true if the content can be highlighted and copied
    • Titles and headings are defined
    • Contrast requirements are met
    • Links have purpose and are clear in context
    • Instructions do not rely on sensory characteristics
    • Images have alternatives
    • Tables have descriptions
    • Bookmarks are available to help the user navigate.

Maps

Maps are non-accessible by design; they are visual ways of interacting with directions and information. There is an exemption for maps in the Regulations because of this, but providing that there is an obvious alternative method of providing the information that the map is displaying on the page (e.g. an address pinned on a map is listed in text form below it).

Responsiveness

Several additional checks should be performed on the page to ensure that it is widely compatible with assistive tools and different devices. It could be useful to do these tests on another device/OS (e.g. a mobile), with things to look out for including:

  • Content displaying properly when text spacing, or line height is increased
  • All functionality can be performed with a single touch/click
  • Functionality dependent on clicking/touching responds when the click is lifted rather than pressed (onmouseup should be used)
  • The web page displays and is functional on a touch-screen mobile device
  • Content is not obscured, and horizontal scrolling not enabled when viewport width is decreased to 320px
  • The page is readable and functional when zoomed to 200%.
  • Content and functionality are not lost when zoomed to 200%.