WCAG 2.0 — Accessibility Principles And Guidelines - Vanseo Design |
| WCAG 2.0 — Accessibility Principles And Guidelines Posted: 22 Jun 2015 05:30 AM PDT Where do you start? Where do you find the guidance to help you build more accessible websites and web apps? Both are questions I asked myself when I began this journey into learning more about web accessibility. I found the initial guidance I was looking for in the Web Content Accessibility Guidelines (WCAG).
 The guidelines cover a lot and you can get lost in the details at times, but once you learn your way around a little and have some context in place you'll be able to weave in and out of the details to your liking. WCAG defines web content in general terms as the information in a web page or web application. It can include text, images, audio, video, and even code and markup for structure and presentation. Following the guidelines will make your content more accessible to a wider range of people with disabilities and it should make your content more usable in general. The Web Accessibility Initiative (WAI)Before digging into WCAG, I want to point you to another section of the W3C first. The Web Accessibility Initiative (WAI) section on the W3C's website offers some general context and points you to documents that provide technical details. There's a lot of information here that you can get lost in as well, but it's easier to find your way around and because of the many resources, the pages serve as good jumping off points. One of these jumping off points for me was this page showing the main WCAG documents you'll likely refer to time and again.
I'm not sure how quick the quick reference is, but it can serve as a checklist to find things you may have overlooked. It's strength is that it can be customized to only show a few guidelines at a time, such as HTML techniques and failures to meet the highest level of compliance (AAA) or the required CSS techniques necessary for level A compliance. I think the quick reference will be most useful after you've learned more. It'll serve as a good reference and checklist. The latter two documents (Understanding WCAG and Techniques for WCAG) are mainly lists of links to details about specific guidelines. These will be most useful as reference material when you want dig deeper into any of the guidelines. The word technique is something of a misnomer. The WCAG techniques show examples of things you might do, such as add a skip link at the top of every page, as opposed to offering specifics for how you might implement the example. You won't need help for many of the techniques, but understand if you don't know how to implement one, you probably won't find the information through the Techniques for WCAG documents. They're what to do more than how to do it. As with the quick reference, I think both documents can confuse more than help until you have a little more context so I want to focus on the one document I haven't mentioned yet, the W3C standard for WCAG 2.0. The Web Content Accessibility Guidelines (WCAG) 2.0WCAG exists to show how to make web content more accessible to people with various disabilities. I talked about five common types of disabilities defined by the WAI last week, but here they are again.
Unfortunately WCAG can't address every possible degree of every possible disability. No set of documents could. Still, following the guidelines will make your sites more accessible and more usable in general. WCAG Layers of GuidanceBecause different people with different needs will make use of the various WCAG documents, those documents provide several layers of guidance from the general to the specific are provided. These layers include:
The principles are the most general and under each principle are multiple levels of guidelines. Each guideline links to specifics for both criteria and techniques to successfully meet the guideline. The guidelines, criteria, and techniques are further broken down into three levels of compliance, A, AA, and AAA, with the last being the most difficult to achieve. You need to successfully meet the criteria of some guidelines to be level A compliant, more to be AA compliant, and the remainder to be AAA compliant. This is why I think context will help a lot here. Much of the documentation is reference and cross reference material for you to look up. Before you can do that though, it helps to understand what you want to look up. Principles and GuidelinesAt the top of the hierarchy are the four principles of accessibility, which are perceivable, operable, understandable, and robust. Under the principles are multiple levels of guidelines and it's hard to talk about one without the other. In total there are twelve top level guidelines below the principles, each with additional sub-guidelines to achieve the different levels of compliance. Assuming I counted right, which is a larger assumption than it should be, there are 25 sub-guidelines for level A compliance, an additional 13 guidelines for level AA compliance, and 23 more guidelines for complete AAA compliance. Each level needs to meet all the guidelines of the lower levels in addition to its own. The guidelines aren't testable. That's where the success criteria and techniques come in, but for the moment let's focus on the principles and guidelines. Principle 1: Perceivable
The perceivable principle is probably the one you think of most when accessibility is mentioned. The idea is to present alternatives for people who are unable to consume your content as originally created. Give images alt text. Add captions to images and video. Create content in multiple ways. Write it out, record it, show it as an image. Make your content presentable to assistive devices without any loss of meaning. In general make it easier for people to perceive your content through multiple senses. Four top level guidelines are associated with this principle.
With the exception of the first, each has further sub guidelines, but I won't try to list them all here. You can find all the guidelines and sub guidelines here. The text alternative and time-based media guidelines are about offering alternative versions of content and making sure those alternate versions are equivalent. For example when I record podcasts I present a text version of the recording. It's not a transcription but a somewhat edited version of what I said in the recording. The audio and text aren't the same, but they are equivalent. The adaptable guidelines are about presenting equivalent content across different devices and conditions. Ensuring content is machine readable for example. The distinguishable guidelines refer to things like providing enough color contrast between design elements and offering controls to raise or lower the volume of audio and video files. Principle 2: Operable
Where principle 1 is concerned with all content being perceivable to anyone accessing the site, principle 2 is about navigation and the interface. Make sure all functionality is available from a keyboard in addition to devices like a mouse or trackpad that require fine motor skills. Make sure navigation is present to help people and machines find content and quickly determine where they are in the site. In general provide different options for people to interact with your site. This principles also has four main guidelines, each with additional sub-guidelines that I'm not showing here.
The first group of guidelines naturally deals with keyboard interaction. The second set, enough time, are about allowing visitors to set time limits if they exist and providing controls for some moving information. The seizure guidelines are about avoiding the potential for your design to induce seizures in some people, the navigable guidelines are about helping people find what they want and where they are. When this principle is met, visitors to your site will be able to find their way around the site quickly and easily and they'll be able to use the site as well. The operable principle crosses into website usability, which is something we should already be familiar with. However, I suspect most of us aren't particularly good with the first guideline, though we probably do ok with the other three. Principle 3: Understandable
This principle is fairly straightforward and again concerns things we probably already think about. I would hope the goals of every designer involve helping make the content understandable. The guidelines for this principle suggest content could be made available in multiple languages and the writing should be at an eighth-grade level. Despite the guideline I think the level should depend on the audience for your content and not automatically be written at such a low level. This time there are three main guidelines.
Multiple languages and reading level are included in the readable guidelines. So are things like the use of unusual words or abbreviations. Predictable covers things like a navigation label accurately identifying where it leads. It also covers sticking to conventions once you've established them. If all your in-content links are red then having one be blue would be unpredictable and lead to confusion. Be consistent. The guidelines about input assistance ask us to minimize the potential for errors and to help correct any that might occur. For example an input form requiring a phone number could make clear what inputs are allowed (to perhaps show a number pad on mobile devices) and use regular expressions to ensure that only the correct input is accepted. An error message would make clear which inputs need correcting and how to correct them. Principle 4: Robust
The final principle, robust, is about making sure your content can be reliably accessed by as many user agents and devices as possible. That includes both those that exist today and those predicted to exist tomorrow. For example your site shouldn't trip up a screen reader. We'll get into this more next week when I talk about ARIA. The robust principle has single guideline with a couple of sub-guidelines so I'll list all three here.
As a whole this principle is about maximizing compatibility with user agents and devices. The first sub-guideline is concerned with markup. Things like making sure HTML tags are closed, nesting elements properly, ensuing unique ids, and other things we hopefully already do. The second sub-guideline is concerned with ARIA roles, states, and properties, which I'll start to look at ARIA next week. I'd say the ideas of responsive design and progressive enhancement fit right in with this principle as does coding to standards. I'd say this also makes a good stopping point for today. Closing ThoughtsOne of things I've found difficult in my previous attempts to learn more about accessibility is knowing where to start. It's easy to find specific details, but harder to find a good overview that provide context for those details. The Web Accessibility Initiative (WAI) is a good place to start for less technical information and for resources pointing you to documents with technical details. Your next stop should be the Web Content Accessibility Guidelines (WCAG), which provide context and details for what to do to build more accessible sites. The guidelines are organized to provide several layers of guidance from general principles to specific techniques. Start with these four principles and their guidelines and sub-guidelines to understand the context for the details that will come next. Next week I want to continue talking about WCAG and look at the the more detailed layers of guidance. We'll talk about success criteria and the techniques for achieving success and how you ultimately conform to accessibility standards. Download a free sample from my book Design Fundamentals. The post WCAG 2.0 — Accessibility Principles And Guidelines appeared first on Vanseo Design.      This posting includes an audio/video/photo media file: Download Now |
| You are subscribed to email updates from Vanseo Design To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |