Back in 2010 the Australian Human Rights Commission issued an advisory note on the Disability Discrimination Act and its effects on web accessibility.
Included in that advisory note was a hidden gem: Ten Common Web Accessibility Failures.
Revisiting that list recently, and being ‘glass-half-full’ types here at Access iQ, it occurred to us that what the Commission had really uncovered was 10 easy accessibility wins, not failures.
So with a nod to the Commission, here’s Access iQ’s 10 easy web accessibility wins.
1. (Failure to) Include appropriate text descriptions (such as “alt-text” labels) for images
Including appropriate text descriptions are a really easy way to ensure that images can not only be recognised by screen readers, but also provides context and information in the same way that the image would to a sighted reader.
Text descriptions, among many other aspects of WCAG are covered in Access iQ’s complete guides to web accessibility for content authors, web developers and web designers. Web accessibility issues are also covered in-depth through the University of South Australia’s Professional Certificate in Web Accessibility.
2. (Failure to) Provide accessible alternatives to a visual CAPTCHA
WCAG 2.0 acknowledges that website owners have a need to establish whether a site user is a human — say when subscribing to a newsletter or sending an email — rather than an automated process. However, the use of CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) tools can test the limits of people without a disability let alone people with a disability. For this reason it’s recommended that CAPTCHAs should not be used at all, despite WCAG 2.0 Level A compliance allowing for them. Instead, website owners should:
- Provide an alternative to CAPTCHA, such as email verification
- Providing access to a human customer service representative who can bypass CAPTCHA
- Not requiring CAPTCHAs for authorised users
More on accessibility issues around CAPTCHAs can be read in W3C’s guidance on non-text content.
3. (Failure to) Use technologies (such as HTML5) in ways that are accessible
The W3C is currently working on developing guidance on applying WCAG 2.0 to non-web technologies.
4. (Failure to) Use HTML features appropriately to indicate content structure such as the hierarchy of headings
One way to increase the accessibility of websites is the inclusion of HTML to allow people using screen readers to move around a story or article via headings and subheadings. So, simply use heading 1 (h1) in your content management system’s editor or the appropriate HTML code for the title or top level heading of an article, and heading 2 (h2) for any subheadings or second level headings. Use heading 3 (h3) for any heading below a subheading, and so on.
5. (Failure to) Explicitly associate form input controls with their labels
Some assistive technologies do not correctly handle implicit labels. Some web browsers or other user agents will display a tool tip when the mouse hovers above an input element containing a title attribute. Title attributes are exposed to assistive technology and are displayed as tooltips in many graphical browsers. Tooltips can't be opened via the keyboard, so this information may not be available to sighted keyboard users. So, by using the label element to explicitly associate a form control with a label you will increase accessibility.
You can read more on Using label elements to associate text labels with form controls at the W3C’s site.
6. (Failure to) Ensure sufficient difference between foreground (text) colour and background colour
A lack of contrast between the colour of text and background colour can make website content inaccessible to people who are vision impaired. So, by simply providing enough contrast between text and its background content can be read by people with moderately low vision — that is, people who do not use contrast-enhancing assistive technology. A contrast ratio of 3:1 is the minimum level recommended for standard text and vision. A higher 4.5:1 ratio can be used for people with moderately low visual acuity, congenital or acquired colour deficiencies, or the loss of contrast sensitivity that typically accompanies aging.
You can read more on contrast at the W3C’s site.
7. (Failure to) Identify data tables with Summary or Caption, and failure to mark-up data tables correctly
As WebAIM notes, data tables allow sighted users to quickly scan data and make associations between information sorted in columns and rows. Vision-impaired and people with blindness cannot see these tables so cannot make these visual associations. Proper mark-up is needed to make a programmatic association between elements within the table. When the proper HTML mark-up is in place, users of screen readers can navigate through data tables one cell at a time, and they will hear the column and row headers spoken to them.
You can read more on using caption elements to associate data table captions with data tables at the W3C’s site.
8. (Failure to) Provide a way for users to disable content such as advertisements from flashing rapidly, and (failure to) provide a way for users to stop a page from auto-refreshing
Rapidly-flashing content may cause seizures in susceptible individuals, so it’s important to limit or remove flashing ads and overly frequent auto-refreshing. It’s recommended to avoid flashing at rates that are known to cause seizures if the flashes are bright and large enough. Since some users may be using screen enlargers, this technique limits the flashing of any size content to one, two, or at most three times flashes in any one-second period.
You can read more on ensuring that no component of the content flashes more than three times in any 1-second period at the W3C’s site.
9. (Failure to) Ensure that web pages can be used from the keyboard (that is, without the mouse)
Making sure all content on a website can be accessed through a keyboard alone is a major component of web accessibility. For many people who are vision impaired or blind, using a mouse’s pointer to navigate can make content inaccessible for the reason that the pointer cannot be seen. For people who have motor-related disabilities, using a mouse to navigate can be difficult or impossible as fine motor skills may be absent. People may also rely on speech input and other assistive technologies which mimic keyboard functions. The key here then is to ensure that your website can be navigated just with a keyboard.
10. (Failure to) Alert the user to changes on a web page that are triggered automatically when selecting items from a dropdown menu.
Website owners need to ensure that users have the opportunity to select a drop-down option and choose to ‘go’ to a new page before anything changes. Pages that auto-change when a selection is made — regardless of whether a notification is given that the page is changing — are very tricky for screen readers and don’t allow for people to change their selection if they make a mistake. Auto-changing pages can also be an issue for users who either cannot use a mouse, or who have difficulty seeing the mouse pointer because they cannot control when a page changes. Instead, it is recommended that users are given the choice, via a keyboard, of selecting a page change element then being able to use a key (tab, space or enter) when they are ready to change page. This ensures the user has made a correct choice and that they know a change is coming.
You can read more on dropdown menus at the W3C’s page on Focus.
Want to learn more about WCAG 2.0 and web accessibility?
The Professional Certificate in Web Accessibility, a university-accredited online qualification jointly conducted by W3C member Media Access Australia and the University of South Australia, is a fully assessed six-week program that covers both accessibility principles and techniques. The course provides students will all the essentials needed to achieve compliance with international best practice in accessibility.