- From: Steve Lee <steve@opendirective.com>
- Date: Thu, 29 Oct 2015 10:53:28 +0000
- To: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
There a few interesting initiatives in this area which might well benefit coga AT I wonder if it would help Ayelet's coga personalisation work? eg Might it be possible to create a script that uses heuristics to attempts to add the new ARIA (coga*) attributes to existing content that does not have them. 1) Mozilla https://wicg.github.io/a11yapi/ The API provides bunch of interfaces that are used to express the semantics of web content in a way that assistive technologies (AT) knows how to deal with. Also it provides the ability to search and traverse the content and interact with it. It has a way to extend existing semantics of the markup, and add new semantics for inaccessible content like drawings made using the canvas element. Each piece of semantic content has an associated accessible element the AT operates on. 2) WAPA is another interesting initiative to address this issue, it builds on the Mozilla work Joseph highlighted and others (HT Leonie Watson). Apparently it can be tried in MS Edge. https://github.com/cyns/wapa/blob/master/ScriptAccessibility.md https://discourse.wicg.io/t/script-based-accessibility-for-web-applications/1112 This Script Based Web Accessibility API allows more direct communication between web applications and platform accessibility APIs. It includes three pieces * A way for web authors to provide ARIA name-value pairs (properties) to platform accessibility APIs from script, without requiring an element with those aria properties in the Document object. * A way for web authors to react in script to method calls from platform accessibility APIs (actions) * A mechanism for handling accessibility information for virtualized content, where the DOM contains only a subset of the actual dataset or document. Steve Lee OpenDirective http://opendirective.com
Received on Thursday, 29 October 2015 10:53:56 UTC