Accessify Wiki

I should have written this a while ago … I have now. Yay!

What is Accessify Wiki?

Accessify Wiki is a machine and human readable way of describing specific accessibility fixes for an arbitrary HTML web page, and a means of delivering those fixes to the user in their browser, without being the owner or publisher of the web page.

Accessibility icon 2 Accessibility icon 1

Why Accessify Wiki?

Accessify Wiki envisages a world where you really need to achieve something on a web page, book train tickets, read some content, or whatever, and there’s an accessibility problem which prevents you from completing your task.

The owner of the page(s) can’t make the fix in a timely fashion* *, so you reach out to ask if the community can help you crowd-source the solution, using Accessify Wiki.

And, the community pulls through.

In due course, the owner of the page(s), will hopefully incorporate the accessibility fix or fixes, completing a virtuous circle.

Note, the web-site owner/publisher remains ultimately responsible for fixing accessibility issues. Accessify Wiki merely aims to facilitate a pragmatic stop-gap.

Where did it come from?

Accessify Wiki grew out of my experience with the Greasemonkey user-Javascript manager for Firefox, and contributions to accessifyhtml5.js.

Initial experimentation happened in ScraperWiki, and the legacy Wiki, is hosted on Wikia. The legacy API, bookmarklet and user Javascript were developed between April 2013 and June 2014. In 2016, I started a new Wiki written in Markdown, powered by Jekyll and hosted on GitHub Pages.

Accessify Wiki introduction, on SlideShare

Describing a fix

The specification of accessibility fixes comprises two parts.


There is a CONFIG object defining which URLs/ pages the fixes apply to (expressed in YAML format) …

  - 'https://**'
  - 'https://**'
  - '*'
  - ''
  # ...
default_locale: en-GB
  - Nick @nfreear
created: '2013-04-03T19:34+01:00'


…And, a set of selectors, with HTML attribute-value pairs, that define the fixes.

# ...
  aria-label: Popup
'.gb_o > a.gb_wa':
  role: button
  title: Close
  aria-label: "Close 'New feature' popup"

Is it secure?

The Javascript uses a whitelist to define which HTML attributes can be added or amended. So, attributes including alt, aria-label and role are allowed, but Javascript event handlers including onclick would not be allowed. The accessibility fixes are currently exposed via a JSON and JSONP API.

A new API would deprecate JSON-P in favour of CORS headers.

Note, that current implementations of Accessify Wiki may be blocked on some sites by a Content Security Policy.

Continuous integration

The system can use the test_urls listed in the config object to periodically test the number of selectors and attribute-value pairs that successfully match. When the hit/miss ratio goes below a threshold, this can be flagged to the Wiki maintainers/editors.

This provides an automated way to continuously test and monitor quality.

How are fixes applied?

There is currently an Accessify bookmarklet, and a user Javascript.

  function (D, AC5U) {
    var s = D.createElement('script'); // var%20s= ...
    s.src = '' + Math.random();
    s.onerror = function (e) { console.error('JS onload error. Probably CSP?',, e) };
)(document, {})

In the future, I envision these being used as the basis for browser add-ons/extensions.

What next?

The initial phase of Accessify Wiki was a frenetic period of development and testing. Since then I’ve had conversations, but never moved on to the next stages.

I would love to conduct a pilot study to test the efficacy of the prototype system(s) with real users, and with assistive technologies.

A colleague has suggested the use of Accessify Wiki for teaching and learning, which is an interesting idea that I’d love to explore further.

And, I need to do some outreach work within the accessibility, dis-ability and possibly open-source communities.

Here’s some new code.

'SM' comments disabled.

'ID' comments disabled.