This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.
Spec Review/Insert
Under review:
Cynthia Shelly
Migrated from Cynthia's preliminary feedback
3.5.1 document.open(replace) should describe what happens to the accessibility APIs when the existing document is destroyed. Maybe as part of unload? [1]
Cynthia to file bug against mapping document Bug 13509
This reminds me that document parsing should maybe also talk about setting up the accessibility APIs? [2]
Cynthia to file bug against mapping document Bug 13510
Cynthia to file bug to improve referencing of that document Bug 13511
I believe that this line covers any AT that is getting info directly from the DOM. Can anyone confirm? Unregister all event listeners registered on the Document node and its descendants.
Cynthia to file bug Bug 13654
3.5.3 Document.write(...) has this big warning on it This method has very idiosyncratic behavior. In some cases, this method can affect the state of the HTML parser while the parser is running, resulting in a DOM that does not correspond to the source of the document. In other cases, the call can clear the current page first, as if document.open() had been called. In yet more cases, the method is simply ignored, or throws an exception. To make matters worse, the exact behavior of this method can in some cases be dependent on network latency, which can lead to failures that are very hard to debug. For all these reasons, use of this method is strongly discouraged.
I believe this is the behavior that people have sometimes though caused accessibility problems. I have never encountered problems with AT and document.write. Having a DOM that doesn't correspond to the source happens with lots of other script too, so I'm not sure why that is a problem. Does anyone have documented test cases of where document.write is a problem (with a specific page, browser and AT combination)?
If so, can we document that as part of the warning, and also discuss in WCAG 2.0 techniques?
discuss, Cynthia to discuss with Rich and Steve
3.5.5 and 3.5.6 innerHTML, outerHTML, insertAdjacentHTML Document how these impact Accessibility API Tree, and what events get fired (API and OS events)
discuss with mapping team
I think DOM-based AT has to rely on mutation events here, which can be slow, and which they don't like. Can we talk to some AT vendors about how to improve this? Maybe by adding a specialized event.
Cynthia to file bug Bug 13512
These are REALLY useful for doing accessible scripting, since they can easily add new content into the DOM in the correct order (for screen-reader reading and tabbing). These are good candidates for HTML 5 WCAG 2.0 techniques. But, we need to make sure that they will be sufficiently performant in AT.
Cynthia to put starter techniques in WCAG Techniques wiki or raise agenda items to WCAG WG