2015-11-14-accessify-wiki.md

published	layout	title	date	x-created	categories	tags
false	post	Accessify Wiki	2016-01-06 09:30:00 -0800	2015-11-14 12:40:00 -0800		accessibility WAI-ARIA javascript

This post is lo-o-oong overdue!

I started development on the prototype Accessify Wiki on 14 April 2013 and paused work on 1 June 2014. And really, its high time I tried to explain just what it's for and how it works...

Raison d'être

Accessibility guidelines and technical standards, outreach and education, and partnership with those who develop web sites and services that contain accessibility problems. These are all good, valuable approaches to tackling Web accessibility. However, there are times when these efforts don't produce the desired result.

A web site owner may be willing to fix accessibility problems, but want to put the issues into the next re-design in 6 months time. A site owner may simply prove unresponsive, but end-users still need to use the service in question. Or, a developer may wish to use a third-party library, recognises that it contains issues, but doesn't have time to collaborate on fixing the library in their current project (this last issue is one that I face as a developer on fast-paced research projects).

We can summarize these potential problems as:

• Lack of willingness,
• Timeliness,
• Dependency on third-party libraries and services,

Given the challenges, I've been looking for a creative, pragmatic solution that would build on and compliment the existing approaches to fixing accessibility on the Web.

Anatomy of a fix

Suppose we have the following snippet of HTML on a page — an image that when pressed using a mouse closes a dialog box within the page, via Javascript.

HTML before

{% highlight html linenos %} {% endhighlight %}

There are various accessibility issues with the above HTML snippet, so below is an imaginary fix, written in YAML on the Accessify Wiki.

The fix

{% highlight yaml linenos %} CONFIG: include: - http://example.org/* test_urls: - http://example.org/test-page-1.html

img[ src *= close-button ]: tabindex: 0 role: button alt: Close dialog

Another fix

...

{% endhighlight %}

Line one defines a _CONFIG_ object, with two required entries, include and test_urls. include contains one or more URL patterns (glob syntax), specifying the set of pages on which these fix(es) should be applied. test_urls defines one or more URLs to specific pages that can be used to test the fixes.

Line 7 contains a selector as used in CSS stylesheets, jQuery and other contexts. In this case it says, select images whose src attribute contains the text string close-button. Lines 8–10 define three attributes that need to be added to the selected HTML elments: tabindex, role and alt (ALT-ernative text), and there respective values.

Note, as the fix is written in YAML, we can dispense with most (almost all), of the quote characters used in JSON, making the result more readable.

HTML after

When the fix is injected via Javascript, it results in the following HTML:

{% highlight html linenos %} {% endhighlight %}

• A tabindex of 0 allows keyboard users to navigate to the button using the TAB key,
• A role of button allows screen readers like JAWS to announce this element as a button, and
• The alt attribute describes to the user what action will be taken by pressing the button.

Our image that looks like a button, now feels like a button (or as WCAG 2.0 says, it is "perceivable, operable, usable and robust" — POUR).

Fix complete!

And, to stress the fix has been implemented without access to the server hosting this example page. It is implemented via a third-party service, and integrated into the page on a per-user basis, via an add-on, browser extension or similar technology, within the user's browser.

In future posts I'll discuss the anatomy of the Accessify Wiki software system, and the relationship of Accessify Wiki to so-called accessibility middleware.

---

Anatomy of a system