Better Accessibility with Javascript

What do we mean by accessibility?

Categoring for people with disabilities:

• Visual
• Auditory
• Cognitive
• Motor

We tend to think of these groups as being served by specific technologies or approaches:

Thinking about accessibility is more than thinking about disabilities.

We should also consider age, education and cultural differences in our audience.

Internet bandwidth may also be an accessbility issue.

Guidelines, legal frameworks, and ethical and practical issues

The UN Convention on the Rights of Persons with Disabilities recognizes access to information and communications technologies, including the Web, as a basic human right.

Legislative frameworks exist in many countries, including Germany, the UK and the US. These typically apply to government organisations and organisations that receive state funding.

However it can be hard to find practical examples of how to make web sites and applications accessible, especially if you are retrofitting an existing app or CMS.

The W3C has a nice introduction to the importance of web accessibility and a number of working groups developing standards for accessibility.

The most relevant standards for us are WCAG and WAI-ARIA.

Web Content Accessibility Guidelines (WCAG)

Set of recommendations for making web content more accessible, made up of testable statements that are not technology-specific.

• Perceivable - present content in different ways, e.g. text alternatives for images and video.
• Operable - keyboard navigation, clear navigation structures.
• Understandable - web pages should behave in predictable ways and provide user feedback.
• Robust - compatible with current and future user agents.

Web Content Accessibility Guidelines (WCAG)

The specification is divided into 3 priority levels (A to AAA). A is an absolute minimum for accessibility.

WCAG form the basis for most relevant legislation and guidelines, including the UK, EU, and Germany.

Accessible Rich Internet Applications (WAI-ARIA)

WAI-ARIA is a response to the increasing complexity of web applications. As websites are no longer comprised of static documents, assistive technologies need to be informed of the role of various elements in the document (e.g. navigation, search, filtering) and of their state (new content has been loaded, a user feedback message has appeared).

Accessible Rich Internet Applications (WAI-ARIA)

Landmark roles are useful and widely adopted. Use these to specify the purpose of parts of a website (e.g. navigation, main content, additional content).

Widgets and application markup provide semantic information about state changes in web applications. The documentation is quite abstract and there aren't many practical examples out there. Also support by assistive technologies is still inconsistent.

Accessible jQuery-ui Components Demonstration has some interesting examples.

German Legislation - BITV 2.0

Anlage 1

Technical specification that draws heavily on the WCAG standards, covering things like alt attributes on images and title attributes on links, keyboard navigation and user feedback.

Divided into Priorität 1 (less onerous) and Priorität 2 (more onerous).

Online self assessments are available, or you can pay for an audit.

German Legislation - BITV 2.0

Anlage 2

Specifies the minimum amount of site content that should be made available in simple text and sign language. To fulfill these requirements you will need to work with certified professionals.

UK Legislation - Disability Discrimination Act & PAS 78

Disability Discrimination Act

PAS 78: Guide to good practice in commissioning accessible websites

The DDA legislation is also based on the WCAG standards.

The PAS is an extra document that provides non-technical advice on commissioning, planning, designing and testing an accessible website.

UK Legislation - Disability Discrimination Act & PAS 78

The PAS is a really useful and practical document that recognises that implementing WCAG could be too hard or expensive for certain organisations.

Instead it advises organisations to identify the "core tasks" that users will complete on the website, and make sure these tasks can be achieved by all users. There's a focus on user profiles, use cases and task oriented testing.

From this it should be clear that good accessibility design = good usability design.

Some Handy Code Fragments

Logical tab index

  jQuery(document).ready(function($) {
    $('a, input, select, button, textarea').attr('tabindex',0);
  });

Skip navigation

  .skip-nav {
	position:fixed;
	top:0px;
	bottom:0px;
	height:0;
	width:0;
	overflow:hidden;
  }

  .skip-nav:focus {
	overflow:visible;
	background:black;
	padding:5px;
	color:white;
	display:block;
	position: static;
	width:100%;
	height:30px;
  }

Screen reader text

  /* Text meant only for screen readers. */
  .screen-reader-text {
	clip: rect(1px, 1px, 1px, 1px);
	position: absolute !important;
	height: 1px;
	width: 1px;
	overflow: hidden;
  }

Adapting Popular Libraries

Leaflet

Owl Carousel

Isotope

Testing

Functionality testing

• Windows - JAWS - Chrome, Firefox and IE behave differently (hooray!)
• Mac - VoiceOver - Cmd + F5 to get started
• Tablets and phones

Task based testing

• Encourage error detection!
• Set goal based tasks for your testers.
• E.g. make a booking, find a contact number, research a piece of information.
• Elicit feedback on whether they were successful, if not why not, and how the process could be improved.
• Also ask for general feedback/critique.