Access iQ has trawled through its growing list of website accessibility audits to bring you nine of the most common issues we uncover.
In a printed document, headings provide structure for information presented on a page. The same thing goes for webpages. However, headings are often not correctly marked up on a webpage, so assistive technology such as screen readers cannot correctly identify and read these headings. The end result is that users (typically those who are blind or have a vision impairment) who rely on a screen reader cannot easily navigate the site. For this reason, using the correct HTML markup <h1, h2, h3 and so on> is essential. The relevant WCAG 2.0 guideline(s) to follow: 1.3.1 Info and Relationships (A), and, 4.1.2 Name, Role, Value (A).
Web browsers need to show users which element(s) of the site has focus—be it a link, an image, a form or some other element. That also applies for site users who may rely on assistive technology. For users who may have vision impairments it is important that the focus has sufficient contrast and can be easily discerned. For users relying on assistive technology, it is also important that each site element is properly coded so that a tool such as a screen reader can recognise each element, and, that the user can Tab through each element using only a keyboard. The relevant WCAG 2.0 guideline(s) to follow: 2.4.7 Visible Focus (AA).
Alternative text for images
Because users with vision impairments may not be able to discern the information or context shown in an image, this information and context needs to be supplied through a meaningful alternate description (alt text) of the image that assistive technology can ‘read’. This goes for all images including background images, social media icons and the magnifying glass in the search area. The only exception is for purely decorative images, for which a 'null' alt text can be applied so assistive technology knows to ignore those images. It is particularly important to have appropriate alt text for images of text and linked images. The relevant WCAG 2.0 guideline(s) to follow: 1.1.1 Text Alternatives (A).
Having sufficient colour contrast is important for users with vision impairments, such as colour blindness, low vision, and macular degeneration. The easiest way to check if there is sufficient contrast is by using a colour contrast analyser, such as the one available from the Paciello Group. The relevant WCAG 2.0 guideline(s) to follow: 1.4.3 Colour Contrast (Minimum) (AA), and 1.4.6 Colour Contrast (Enhanced) (AAA).
An easy feature to add to a website to make it accessible is to help users to bypass or skip over repeated blocks of content by adding ‘skip to’ links. This aids in navigation and is particularly useful for users relying on screen readers and/or keyboard navigation. The relevant WCAG 2.0 guideline(s) to follow: 2.4.1 Bypass Blocks (A).
Many website users rely on a keyboard only—or assistive technology which uses the same level of functionality as a keyboard—to navigate websites. However, inaccessible websites often have ‘keyboard traps’, where a user navigates through a site using the TAB key, but then finds themselves stuck in an element they cannot navigate out of. The result is that the user has to close the browser, go to the complaints section or somebody else’s site. The relevant WCAG 2.0 guideline(s) to follow: 2.1.2 No Keyboard Trap.
Carousels and slideshows: no controls
Along with colour contrast and alt text issues, a common accessibility issue for carousels and slideshows is a lack of controls: pause, play, forward and back. To make carousels or slideshows accessible for users of assistive technology among other users, you must be able to pause, play, and navigate through previous and following items through buttons on your carousel.,The relevant WCAG 2.0 guideline(s) to follow: 2.2.2 Pause, stop, hide.
With more and more organisations seeking to shift engagement with their customers to an online channel, forms become an essential mechanism to collect and convey information. Forms must be easy to understand and complete for all users including older Australians and people with disabilities. To avoid creating admin bottlenecks from poorly designed forms, form labels should be explicitly associated with their input fields, form controls should be associated with the title attribute if a label cannot be used, form labels should be grouped together visually, and use fieldset and legend to create semantic structure. The relevant WCAG 2.0 guideline(s) to follow: Success Criterion 1.1.1: Non-text content, Success Criterion 1.3.1 Info and relationships, Success Criterion 2.4.6 Headings and labels, and Success Criterion 3.3.2 Labels or instructions.
Websites often use Captchas to ensure the security of customer transactions and user registrations, however, they are generally regarded as inaccessible to users with disabilities due to the difficulty of accurately perceiving and hearing letters and numbers. So, where possible do not use them, and instead, consider using an alternative such as human test questions, honeypot trap, spam filters or heuristic checks. If you do have to use a Captcha, ensure that all components within a CAPTCHA, such as buttons comply with all other accessibility requirements including keyboard accessibility and visible focus. Often a third-party CAPTCHA that claims to be accessible will only provide an audio alternative but not meet other accessibility requirements. The relevant WCAG 2.0 guideline(s) to follow: Understanding SC 1.1.1, G143: Providing a text alternative that describes the purpose of the CAPTCHA.