Home

Even Grounds, Accessibility Consulting

Making web sites, documents, software and hardware accessible to people with disabilities. Accessibility, WCAG and Section 508 compliance testing and auditing.

  • Services
  • About Us
  • Customers
  • Contact Us
  • Articles
  • Blog
  • Developers' Corner
  • Press
  • Resources

Skip table of contents

  • WCAG Tutorial
  • Introduction
  • About The Author
  • Using The Tutorial
  • WCAG 2.0 Overview
  • Navigating The WCAG 2.0 Documents
  • Principle 1: Perceivable
    • 1.1: Text Alternatives
    • 1.2: Time-based Media
    • 1.3: Adaptable
    • 1.4: Distinguishable
  • Principle 2: Operable
    • 2.1: Keyboard Accessible
    • 2.2: Enough Time
    • 2.3: Seizures
    • 2.4: Navigable
  • Principle 3: Understandable
    • 3.1: Readable
    • 3.2: Predictable
    • 3.3: Input Assistance
  • Principle 4: Robust
    • 4.1: Compatible
  • Appendix
    • Contrast Analyser
    • HTML And CSS Validators
    • Web Accessibility Toolbar

Do you need help with accessibility? Hire us!

4.1: Compatible

Guideline 4.1: Maximize compatibility with current and future user agents, including assistive technologies.

This guideline contains techniques you can use to ensure that your product is compatible with existing and future user agents. These include all types of assistive technologies such as screen readers.

Most types of technologies evolve at a very fast pace. As a result, developers have to constantly work hard to keep up with these technologies. This can be a very difficult task which certain developers tend to overlook. To address this concern, this guideline helps developers ensure their products follow a specific convention and remain compatible with any type of assistive technology and browser.

4.1.1: Parsing (Level A)

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. (Level A)

Through this success criterion, developers can test if user agents can interpret and parse the content of a web page. Parsing refers to a process where codes are divided into functional components in order for an application to make use of them.

If user agents are capable of parsing the content into a data structure, there would be a good possibility that various user agents would present the information in a similar manner. So, if for instance, you have confirmed that a specific browser can properly parse the content of your page, you can be certain that other browsers can parse the content and display it correctly. You can use the HTML and CSS validators to help you in this success criterion.

To achieve this, you should make sure that all your HTML tags are opened and closed properly. For instance, if you have a document containing several heading level 2 texts, each of these texts should be marked up with <h2> at the start and </h2> at the end. Failure to do so will cause other texts to appear as headings. This is invalid and it can negatively affect the browsing experience of certain users.

Another example: If you fail to close the <tr> tag in a table, the content will still look the same. However, the content won’t be valid although its representation may look correct.

4.1.2: Name, Role, Value (Level A)

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. (Level A)

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

This success criterion helps website developers ensure that the user interface controls they include in their pages are compatible with assistive technologies. Examples of user interface controls are buttons, checkboxes, and treeviews.

Usually, web developers that use standard controls from accessible technologies do not have to be concerned with this criterion. This is because these controls meet the conditions set by this provision.

On the other hand, developers that use custom controls have to take additional measures to make sure these controls provide the information needed by assistive technologies. This also applies to developers who create interface elements that have roles and functions that are different from those they have been set to do.

Examples of these measures include verifying if assistive technologies can determine the state of the custom controls in the page. For instance, an assistive technology needs to be able to determine if it has set its focus on the control, or if it has lost its focus on the control. Assistive technologies also have to determine if they have selected the custom control, assuming that it is a radio button or a checkbox.


  • Previous: Principle 4: Robust
  • Next: Appendix
Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Facebook
  • Google
  • Yahoo
  • Technorati

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

This blog uses CommentLuv plugin which will try and parse your sites feed and display a link to your last post, please be patient while it tries to find it for you
CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.

Accessibility Tips and Tricks


RSS

  • Articles
  • Blog
  • Developers' Corner
  • News
  • Press

Follow us on Twitter, YouTube, or on Facebook

 

Privacy Policy

Copyright 2007-2011 - Even Grounds Inc., Accessibility Consulting