Making Your Website Accessible Part 1: understanding WCAGPosted: October 15, 2012 | Author: Cynthia Ng | Filed under: library, usability, web | Tags: a11y, accessibility, WCAG | 2 Comments »
With more and more services and resources becoming digital, web accessibility has become an ever increasingly important topic. As a result, I thought a summary of my findings would be useful to others that are involved with web services.
What is Web Accessibility?
Some define web accessibility to mean making the web accessible to those with disabilities (including visual, auditory, motor, and cognitive) 1. However, I prefer the more general meaning of making the web accessible equally to everyone, including those with disabilities 2. To take this further, regardless of whether someone has a disability, they should be able to access information in their preferred manner including using any browser, operating system, or device.
A quick (but common) example of a problem is how a user is expected to control a video if they cannot use a mouse to click on buttons (they may depend on a keyboard or be visually impaired), especially when most videos still use some form of Flash. Try it sometime, and see what happens. Web accessibility guidelines, such as WCAG, attempt to address these issues.
What is WCAG?
The Web Content Accessibility Guidelines are just that, a set of guidelines, written by the Web Accessibility Initiative (WAI) group of the W3C. Currently, it’s at version 2.0, but many organizations still use version 1.0 (usually with modifications to make it more current).
- The Breakdown of WCAG
Many (myself included) find WCAG to be difficult to navigate and comprehend. To get a better idea of ideas behind the guidelines, reading a summary can be of great help. The WCAG part of the Web Accessibility Initiative (WAI) site provides a good summary of the guidelines:
- Provide text alternatives for non-text content.
- Provide captions and other alternatives for multimedia.
- Create content that can be presented in different ways,including by assistive technologies, without losing meaning.
- Make it easier for users to see and hear content.
- Make all functionality available from a keyboard.
- Give users enough time to read and use content.
- Do not use content that causes seizures.
- Help users navigate and find content.
- Make text readable and understandable.
- Make content appear and operate in predictable ways.
- Help users avoid and correct mistakes.
- Maximize compatibility with current and future user tools.
Even if you don’t follow the specifics of WCAG, these are good general guidelines for web accessibility. While many of these might seem like common sense, the average person will not be detrimentally affected by not following guidelines. Also, some actually can have grave consequences (I always like to point out that content should not cause seizures).
The specific guidelines expand on these ideas and provide more detail on how each guideline might be met. To wade through the specifics, I suggest using the quick reference, How to Meet WCAG 2.0, and use the customization based on your current technologies and focus. By unchecking everything, except the level(s) you expect to meet, it also provides a good checklist.
- A Note on Techniques
In most cases, the sufficient techniques and failures listed under each guideline are quite useful as examples of how you might meet (or fail) each guideline. On the other hand, the techniques are “informative” and are not necessarily the best method in fulfilling a given guideline. (See my critcism below.) You might also give advisory techniques a glance if you’re keen on knowing how to further enhance accessibility, but then my view is that there is enough to deal with without getting into even more detail.
Criticisms & Lessons Learned
WCAG is not without criticism. The wikipedia article on web accessibility gives a nice short blurb and links to articles of interest. From what I’ve read, the three most compelling arguments against WCAG2.0 specifically are that:
- Level AAA is impractical to meet,
- even at Level AAA, meeting WCAG2.0 does not make your website accessible, and
- the documentation is difficult to navigate/understand.
To briefly explain the second point, as I mentioned, part of web accessibility is to make your website easily accessible on any device, but WCAG does not directly address this issue (which you could address for example through responsive design, as explained by Lisa in the last TechConnect post).
My biggest criticism though of WCAG2.0 is that the documentation (in particular, the techniques) is not current.
For example, under Sufficient Techniques for 1.3.1, Technique H73 tells you to use the summary attribute in table elements to provide an overview of what a given table is about. However, the summary attribute in HTML5 is deprecated (which I didn’t discover until I put a page with a table through the W3C validator).
Why Should You Care?
Despite its shortcomings, WCAG provides an excellent (base) set of guidelines to follow. Even if you choose not follow WCAG, consider customizing it to fit your organization’s needs.
- Increased Access
If you’re reading this, you’re more than likely working at a public institution of some sort. Public institutions serve a very diverse group of people, and while persons with disabilities is a minority, we’re to serve one minority as well as any other and the majority as well (at least ideally).
Improving web accessibility helps a diverse audience in and of itself. Everything from mild to more extreme cases, the guidelines help to serve:
- blind users, who will use screen readers
- low vision users, who may use screen readers or magnifying tools
- colourblind users
- mobility impaired users, who might only use a keyboard
- users with cognitive or learning disabilities
- and more…
While in many cases serving one minority can mean taking away from another, that’s not the case here. You can easily improve your site to meet web accessibility requirements without negatively impacting the rest of your audience in any way (it simply might not make any difference).
- Legislation: AODA Regulations
Legislation and regulations are additional reasons to adhere to a set of web accessibility guidelines. Even if it’s not legislated, most institutions (public and private) will have policies and/or mandates that require or promote equal/equivalent access to all users.
In Ontario, Canada we have the Accessibility for Ontarians with Disabilities Act (AODA), which states that under Section 14, subsection 4:
- By January 1, 2014, new internet websites and web content on [public sector] sites must conform with WCAG 2.0 Level A.
- By January 1, 2021, all internet websites and web content must conform with WCAG 2.0 Level AA, other than,
- success criteria 1.2.4 Captions (Live), and
- success criteria 1.2.5 Audio Descriptions (Pre-recorded).
Different countries and provinces/states obviously have different regulations, and I’m not really familiar with others, but I know that many of them use WCAG as well.
If you’re in the US, check out the Section 508 Government website. It focuses on the government regulations for their own departments, but includes lots of resources.
In academic libraries, I would also highly recommend contacting the equivalent disabilities support office (frequently called Access Centre), as they will provide support for staff dealing with accessibility issues.
- Better for Everyone
While web accessibility generally focuses on providing and improving access for persons with disabilities, making sure your site follow a set of guidelines can also improve the experience of your other users as well.
Even something as simple as providing alternative text for images can help ‘regular’ users. What if their internet or your site is slow? What if they blocked (larger) images because they’re on a data plan? What if they’re using a text only browser? (While rare nowadays, not completely unheard of.) Much like when using a screen reader, having alternative text for images means a user would know what they’re missing and if it’s important.
Provided the ideal circumstances, some guidelines can still provide a better user experience.
Make text readable and understandable. –Guideline 3.1
Who wouldn’t want their user to be able to read and understand their site? Making content consistent across the site also improves navigation and browsability of a site.
We all access the web differently. Heck, I have a script blocker, flash blocker, and ad blocker all installed on every browser I regularly use. I really like sites that allow me to use them without unblocking any of those, because I believe that users should be able to do at least the basic things of any given website without ads, scripts, and flash. Web accessibility guidelines can help you make your site more accessible for everyone, and provide a better user experience.
Basically, WCAG is a good source of information and a good set of guidelines to follow. While you need to be cautious of some of the finer details, making your site meet web accessibility guidelines can improve your site not only for those with special needs, but for your regular users as well.
About our Guest Author: Cynthia Ng is currently the Innovative Technologies Librarian (and also filling in for the Web Services Librarian) at Ryerson University Library and Archives. While she is especially interested in web development and services, her focus is on integrating technology into the library in a holistic manner to best serve its user. She is a recent MLIS graduate from the University of British Columbia, and also holds a BEd from UBC. She can be found blogging at Learning (Lib)Tech and on Twitter as @TheRealArty.