WCAG2.0 Level A, your guide part 1

Here we will look at the WCAG2.0 Guidelines level A. This is the most basic level of accessibility and without it, will prevent many people from being able to use your website. It may also impact the level of usability for everyone not just people who may have an impairment.

The guidelines are based on four principles POUR, see the article Get started with WCAG2.0 for an overview.

Perceivable

1.1 Text Alternatives

1.1.1 Non-text Content: Any of your web pages content that is not in regular text, such as images, video, sound, Flash or other similar content that is available to your visitors, must have a text alternative that gives an equivalent purpose, except in the cases listed below.

Regular text is any text that can be selected and understood by other technologies, such as text editors. It does not include text that is embedded into images, videos or spoken within audio. A simple test is to see if you can highlight the text and copy it into a text editor like notepad.

  • For web controls such as buttons or forms you give them text names or text labels that will explain their purpose, see WCAG2.0 4.1 for more details.
  • For time based media, the text alternative should at least give a description of the media, see WCAG2.0 1.2 for more details.
  • When providing a test or exercise in a text format would be invalidated you should at least give a description of the non text content.
  • When the primary purpose is for creating a specific sensory experience, you should at least give a description of the content.
  • When using CAPTCHAs, you should at least give a description that identifies and explains the purpose of the CAPTCHA. You should also provide alternative CAPTCHAs for different types of sensory perception. These may include, visual, audible or touch, see the article Captcha should it stay or should it go.
  • For cases when using visual effect for pure decoration or only for visual formatting, or is not to be shown to people, you should use a method that is not visible to assistive technology. Things like placing decorational images as CSS backgrounds instead of HTML image content.

1.2 Time-based Media

these guidelines do not apply when the audio or video is used as an alternative for text content and is clearly labelled as such. There is more information at WCAG2.0 Understanding Guideline 1.2.

It is worth noting that these guidelines address people with either hearing or visual impairment but do not address accessibility issues for people with both hearing and visual impairments or may not address people with cognitive impairments. Remember any time based media may effect people’s access especially for those who take more time to access and understand the content.

1.2.1 Audio-only and Video-only (Pre-recorded): An alternative for time-based media is available that gives the same information for pre-recorded audio-only content and Either an alternative for time-based media or an audio track is available that gives the same information for pre-recorded video-only content.

1.2.2 Captions (Pre-recorded): Captions are available for all pre-recorded audio content in synchronized media,.

1.2.3 Audio Description or Media Alternative (Pre-recorded): An alternative for time-based media or audio description of the pre-recorded video content is available for synchronized media.

1.3 Adaptable

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. This refers to things like HTML semantics, for an example see the article Get started with Structured Headings.

1.3.2 Meaningful Sequence: When the order in which content is given affects its meaning, a correct reading sequence can be programmatically determined. This refers to things like the tab ordering and the HTML order of content as appose to any visual layout being used. It is there to help ensure assistive technology can follow the order of information as it is intended without out loosing any meaning.

1.3.3 Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. This is to allow people to follow instructions regardless of which Sensory control they are using such as audio, visual or touch.

1.4 Distinguishable

1.4.1 Use of Colour: Colour is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.

Operable

2.1 Keyboard Accessible

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. For example if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not. You are not advised to avoid other input methods like mouse or touch screens but instead allow for both. See the article A Little Accessibility Guide to Device Independence.

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, like the escape key, the user is advised of the method for moving focus away. Common examples of keyboard traps are embedded objects like Flash or JavaScript that takes control over the keyboard input.

2.2 Enough Time

2.2.1 Timing Adjustable: This helps ensure that people can complete tasks without unexpected changes in content or context that are a result of a time limit. You should not use time limits on content unless one of the following applies:

  • People are able to turn off the time limit before it starts.
  • People are able to adjust the time limit over a wide range that is at least ten times the length of the default setting and before it starts.
  • People are warned before the time limit expires and are given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and they are able to extend the time limit at least ten times.
  • The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible.
  • The time limit is essential and extending it would invalidate the activity.
  • The time limit is longer than 20 hours.

2.2.2 Pause, Stop, Hide: For any moving, blinking or scrolling information that starts automatically, or lasts more than five seconds, and is not the only content available, there needs to be a way for people to pause, stop, or hide it unless it’s part of an activity where it is essential. For any auto-updating information that starts automatically and is not the only content available, there needs to be a way for people to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.

Content that is updated periodically by software or that is streamed to the browser is not required to keep or give information that is generated or received between the pause and resume action as this may not be technically possible, and in many cases could be misleading to do so.

An animation that occurs as part of a preload phase or similar case can be treated as essential if interaction cannot occur during that phase for all people and if not indicating progress could confuse people or cause them to think that content was frozen or broken.

2.3 Seizures

2.3.1 Three Flashes or Below Threshold: Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. This is to prevent people susceptible to photo-sensory related Seizures from having attacks provoked by your content. This will include animations, video or interactive content.

If you have any content that may not comply with this guideline, it is important that you make people aware before the content is shown and allow people to choose weather to proceed with the content.

2.4 Navigable

2.4.1 Bypass Blocks: Give people a way to bypass blocks of content that are repeated on multiple Web pages. This refers to things like skip links and is there to help people get to content more easily.

2.4.2 Page Titled: Web pages have titles that describe topic or purpose. This is both a SEO (Search Engine Optimisation) and accessibility requirement. The more relevant and concise the title the better. It should reflect the topic and purpose of the page and not the website in general.

2.4.3 Focus Order: This refers to the order in which items that can have focus like links, form fields, buttons and any control that people can interact with are placed. It is important that this order makes sense to people regardless of the device or assistive technology they may be using.

2.4.4 Link Purpose (In Context): The purpose of each link can make sense from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be confusing to people in general.

Understandable

3.1 Readable

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. This refers to adding a base language to the page that can be used by assistive technology and web browsers.

3.2 Predictable

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. This is to prevent any unexpected behaviour when people are moving focus from one place to another, This includes tabbing or clicking into a text field. You can read more on WCAG2.0 Understanding on focus.

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behaviour before using the component. This is about always informing people of any unpredictable changes, things like a link opens in a new window. As this is not the default action of a link and may cause confusion. For more information see WCAG2.0 Understanding on input.

3.3 Input Assistance

3.3.1 Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. When identifying errors with information entered by people, it is important to do this with text and not through images, colours or sound alone. This is to ensure it is available to everyone regardless of technology used.

3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. This is for things like web forms, search boxes or login screens. Anywhere people need to enter information, suitable instructions and labels should be given.

Robust

4.1 Compatible

This is about following code standards and best coding practices to ensure the code will work equally well across multiple browsers and with various assistive technologies. You can see more about device independence and assistive technologies in the article A Little Accessibility Guide to Device Independence.

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

This is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this guideline when used according to specification.

Conclusion

For WCAG2.0 Level A, the first and lowest level of accessibility guidelines, it has 25 different things to check. These are across all four POUR Principles and broken into guideline categories like 1.1 Text Alternatives.

You can appreciate after reading through these initial guidelines, that knowing a little about assistive technology and how people use these technologies, why the guidelines exist.

My next post will go over each of these 25 checks and explain why I believe they may or may not be tested with automated systems.

Don’t miss another accessibility article!

Enter your email below and get free updates as soon as they become available.


We respect your privacy and do not spam.

Leave a Reply

Your email address will not be published. Required fields are marked *