Accessibility and the EBI

Accessibility refers to the ability of users to access and interact with features and elements of a web page in order to perform tasks. I consider accessibility to be a key part of usability. Generally speaking, when we discuss accessibility, we mean that we want to make web pages and applications accessible to everyone, regardless of factors that may make this challenging for certain people. It is a big mistake to assume that this concerns only blind users of websites. It may concern people who require any kind of assistive technology to access websites, people with epilepsy, people with cognitive problems, and so on.

There are a number of legal requirements for providing accessibility, although it is not always 100% clear how these might apply to different EBI tools and applications!

In the UK, we have the Disability Discrimination Act (DDA) and the Special Educational Needs and Disability Act (SENDA).
In Europe, “e-Accessibility” is governed by European Directives, communicated by EUROPA. In the US, they have Section 508.

Furthermore, applying accessibility rules to the kind of complex tools and applications we produce is especially challenging. However, we do have users who have access issues, and there for we have actual, moral and legal requirements to succeed.

Key things to know for web development

• The W3C’s Web Accessibility Initiative (WAI) publish Web Content Accessibility Guidelines (WCAG)
• WCAG 2.0 superceded WCAG 1.0 on December 11, 2008, and is now the official recommendation of the W3C
• “Most Web sites that conform to WCAG 1.0 will not require significant changes in order to conform to WCAG 2.0, and some may not need any changes.”
• Both EUROPA (http://europa.eu/geninfo/accessibility_policy_en.htm) and the UK Government (see http://archive.cabinetoffice.gov.uk/e-government/ and http://www.direct.gov.uk/en/Hl1/Help/Accessibility/DG_10016906) continue to recommend working towards AA standards, based on the WCAG 1.0 spec
• So let’s follow their lead, and stick with WCAG 1.0 for now  –  if this is official policy, we need only state that

However, the core principle of the WCAG 2.0 recommendation is based on four key “success criteria”, given the acronym POUR:

• Perceivable
• Operable
• Understandable
• Robust

Keeping those in mind would be very wise.

Important: automated accessibility validation (e.g. Cynthia Says) can only catch some accessibility issues. It is not a replacement for testing with real users. Automated testing allows us to satisfy measure a web page against a set of testable heuristics, but it doesn’t demonstrate that user is able to access and use that web page.

I might repeat that a lot!  🙂

Meeting a particular WAI standard

• Priority 1 checkpoints MUST be met to achieve A standard. These are “broad brushstrokes”
• Priority 2 checkpoints SHOULD be aimed for. Ticking all these boxes gets us AA standard
• Priority 3 checkpoints (i.e. aiming for AAA standard) are much more specific and detailed. The WCAG 2.0 document acknowledges that it may not always be possible to meet these. It is very hard to meet them in WCAG 1.0
• EUROPA requirement is only for A standard, so aiming to achieve AA is a winner
• To some extent, we can use things like the Cynthia automatic WAI validator, but lots of stuff needs to be tested manually, with real users. We should involve users throughout the process to inform design and development, and to validate the product
• Manual testing can also cover stuff like R/G colour blindness, and other optical disorders (see colorschemedesigner.com)
• Interfaces, language and processes must be appropriate to the user
• Need to balance needs of novice users with those of experts

WCAG 1.0 Priority 1 checkpoints include:

• screen is readable without stylesheets (turn off CSS!)
• colour alone is not used to convey meaning
• include text alternatives for images and other media
• reduce screen flicker (no awful <blink> tags!!! They went out with the Ark!  –  also less auto-updates and scrolling)
• use <abbr> and <acronym> tags to improve readability and accessibility
• use plain English (or whatever!), written for the user
• clear and consistent navigation
• for data tables, identify row and column headers.

WCAG 1.0 Priority 2 checkpoints include:

• good contrast between foreground and background
• use stylesheets to control layout and presentation
• use relative, not absolute, units for sizing
• ensure that dynamic content is accessible or provide an alternative presentation or page
• use and markup lists and (block)quotes properly
• use the <header> : provide language and expiry information, for example
• use META description and keywords (even though the latter is useless for search engine optimisation)
• tables are only for tabulated data!
• uses <label> in forms

This is not an exhaustive list, but covers a lot of the stuff.

What else do we need to consider?

WAI-ARIA: ARIA is the Web Accessibility Initiative guidance for Accessible Rich Internet Applications.

At the moment, the guidelines are still in draft format, and therefore haven’t been ratified as a full recommendation of the W3C. It is on the horizon, however, and is likely to apply to the kinds of tools and applications produced by the EBI.
“It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.”

ARIA will provide “…new ways for functionality to be provided to assistive technology”.
It allows us to have an extra layer of contextual information.

Like what?
WAI-ARIA provides Web authors with the following:

• Roles to describe the type of widget presented, such as “menu,” “treeitem,” “slider,” and “progressmeter”
• Roles to describe the structure of the Web page, such as headings, regions, and tables (grids)
• Properties to describe the state widgets are in, such as “checked” for a check box, or “haspopup” for a menu.
• Properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates—for example, critical updates may be presented in an alert dialog box, and incidental updates occur within the page
• Properties for drag-and-drop that describe drag sources and drop targets
• A way to provide keyboard navigation for the Web objects and events, such as those mentioned above

It is easy to add these in to what we do, and in fact, Drupal might feature this accessibility richness already.
There is a W3C document that acts as a good WAI-ARIA primer although it is a bit dense and dry.

Note: at the moment, use of ARIA attributes (new namespaces, effectively) will cause a document to fail automatic validation. The W3C are looking at creating or amending a document type definition (DTD) to deal with this. This will happen for XHTML, and not HTML 4.01, since XHTML is extensible. It should also happen for HTML 5 (but let’s not open that can of worms right now!)

It is designed to go hand-in-hand with WCAG 2.0, the official recommendation. WCAG 1.0 is somewhat outdated, when compared to advancements in web-based technology, and better understanding of the needs of disabled users. WAI-ARIA offers better much better accessibility that WCAG 1.0 recommendations alone, however, I cannot see any reason why we can’t do a retrospective combination.

Various useful links

Website of the Web Accessibility Initiative

Usability.net –  Support for EU projects

An excellent review of WCAG2.0, from 2006

Another good round-up of the WCAG 2.0 guidelines from Webcredible

A facility for checking sites/pages against WCAG 2.0 requirements (non-automated)

American accessibility guidelines (some very good stuff, although it refers to American Section 508 rules)

Accessify – the accessibility discussion forum

Commonly asked questions regarding the WAI-ARIA guidelines

Reward for reading this far

A “tech support cheatsheet”, to help you impress friends and family with your computer wizadry.  😉