Followers of the W3C’s Web Content Accessibility Guidelines (WCAG) working group and Web Accessibility Initiative (WAI) Interest Group would have seen a number of emails recently on software packages that claim to be all-in-one web accessibility solutions.
While last month’s column highlighted some useful tools, there is no single tool that can provide a definitive evaluation of a website’s accessibility or make a website accessible.
The challenge is finding out which products are of genuine benefit to avoid investing time and money in a solution that does not meet the full requirements for WCAG 2.0 compliance.
Given the recent spike in accessibility misinformation, I thought it would be a good time to put together a list of top 5 accessibility misconceptions and pitfalls made by decision-makers and developers in trying to address accessibility issues.
1. No one else has captions or audio description on their website, so I don’t need to either
WCAG 1.0 didn’t focus much on captions or audio description due to the extremely limited online video content when the guidelines were released in 1999. This has changed substantially in the past three years.
Captioned video is an ‘A’ level WCAG 2.0 requirement, meaning that if a website is to adopt even the minimal accessibility standards, it must have captioned video. Audio description is an ‘AA’ level requirement, a level which has been widely adopted by governments around the world, including Australia.
The argument that websites don’t need captions has crumbled in recent times with YouTube’s automated captions, the BBC’s iPlayer and the ABC iView all containing captioned video, and third-party devices such as the Boxee Box providing support for online captioned video playback. The BBC iPlayer also supports audio description, and other countries are starting to explore how they can improve their online offerings.
2. Embedded accessibility software is the answer
The most recent software release that sparked the W3C email discussions is called Essential Accessibility, a software package that claims to solve all your accessibility problems: “…the only implementation step required is to display this symbol on the homepage as a clickable icon through which any visitor can download the assistive technology they require free of charge.”
Sounds good in theory, but this software assumes that a person’s disability is a vision impairment, the person is using Windows to access websites, the website has been designed and developed in an accessible way and that people with disabilities are happy to only have access to the limited number of websites with the clickable icon.
By focusing on making websites compliant with W3C standards, developers have the ability to ensure that a website works for people with different disabilities across a wide variety of platforms. Although there used to be an argument that such tools were essential due to the cost of assistive technology, free tools such as WebAnywhere provide a similar service across all websites, and the open-source NVDA or built-in accessibility features in most common computers and devices have also evolved so that such web-integrated software is no longer required.
3. My website is accessible because the evaluation tool told me so
As discussed in last month’s W3C column, evaluation tools can be great in providing guidance as to where some of the accessibility issues may be located on a website, but they do not check for everything. Does your website have audio description in the video? Do the Flash elements contain a keyboard trap? These are just some examples of why it’s still important to manually check and user test a website’s compliance as part of the design and development process.
4. Websites can’t be media-rich and accessible
There’s a very simple answer to this: check out the BBC website. The BBC website is one of the most media-rich in the world and it is always coming up with new and innovative ways to make its content accessible. In addition to the captioned and audio described videos, it also has documentation to help people who want to navigate the website and a recently launched MyDisplay customisation tool.
5. WCAG 2.0 is the only W3C accessibility standard
At the OZeWAI conference last year, a point of frustration was made by some that WAI-related work can often be overlooked and only WCAG seems to get widely acknowledged. In many ways it’s understandable that WCAG should be the most relevant, but I’d strongly recommend that developers have a look through some of the other work being done in WAI that may provide additional opportunities to support the needs of people with disabilities.
As has been discussed in previous columns, other standards such as the Authoring Tool Accessibility Guidelines, User Agent Accessibility Guidelines and WAI-ARIA may be more niche, but are also important if you’re working in areas that could use these technologies.
Dr Scott Hollier represents Media Access Australia on the W3C Advisory Committee and publishes the W3C Column monthly.
Top of page