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.
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?
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) …
include: - 'https://*.google.de/*' - 'https://*.google.co.uk/*' - 'http://www.google.com/*' test_urls: - 'https://google.co.uk/search?q=Accessify+Wiki' # ... default_locale: en-GB authors: - Nick @nfreear created: '2013-04-03T19:34+01:00'
…And, a set of selectors, with HTML attribute-value pairs, that define the fixes.
# ... .gb_o: aria-label: Popup '.gb_o > a.gb_wa': role: button title: Close aria-label: "Close 'New feature' popup"
Is it secure?
So, attributes including
role are allowed,
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.
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?
In the future, I envision these being used as the basis for browser add-ons/extensions.
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.