Coding for Accessibility

You’re most likely here because you need to make sure your coding practices are accessible to people with disabilities.

You might have a specific problem, like:

• how to ensure code for a new site is accessible
• how to review existing code to make sure it complies with requirements
• how to fix or replace existing code that you know has accessibility problems
• how to ensure using JavaScript does not make content inaccessible
• how to use tabindex, longdesc or doctypes to enhance accessibility
• what implications iframes, blink and marquee have for accessibility

Perhaps you need a comprehensive list of likely accessibility issues associated with specific coding techniques – and how to address them. Or maybe you just want to ask a direct question and get a clear, expert response.

You’re in the right place.

OzWiki will tell you what you need to know to make sure the code you use is consistent with accessibility requirements. The Coding section details 51 accessibility problems and how to address them, demonstrating compliance with 37 WCAG Level A success criteria, eight Level AA and six Level AAA success criteria.

As a subscriber, you’ll also be able to request further or more detailed information relating to your specific situation.

See an example

JavaScript event handlers have been used instead of semantic links

Category	Coding
Topic	Links
WCAG SC 1.1.1: Non-text Content	All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed: Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to WCAG 2.0 guideline 4.1 for additional requirements for controls and content that accepts user input.) Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to WCAG 2.0 guideline 1.2 for additional requirements for media.) Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content. Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content. CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities. Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology. http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv-all.html See more errors for this SC
Level	A
Technique(s)	G115: Using semantic elements to mark up structure
Impact	High

Error

JavaScript event handlers have been used instead of semantic links. When Javascript is disabled these links don't work.

Incorrect Example(s)

Example 1

Array

Solution

Replace these JavaScript links with the semantic A HREF element.

OzWiki is an accessible resource that provides best known methods to achieve A & AA level design and interaction for web content in areas such as Audio, Video, Link, Captcha, Maps, Navigation and more. These outlined accessibility errors, examples and solutions help you become 508 compliant by demonstrating associated WCAG 2.0 success criteria and techniques.

Gain access to more detailed information on all OzWiki categories for only $39/month by purchasing a subscription today! You can cancel your subscription at any time.