review of HTML 5 section 3.5 Dynamic Markup

I was asked to review HTML 5 section 3.5 Dynamic Markup [1]

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? [2]

This reminds me that document parsing should maybe also talk about setting up the accessibility APIs? [3]

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<http://www.w3.org/TR/2011/WD-html5-20110525/infrastructure.html#document> node and its descendants.

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<http://www.w3.org/TR/2011/WD-html5-20110525/parsing.html#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()<http://www.w3.org/TR/2011/WD-html5-20110525/apis-in-html-documents.html#dom-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?

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)

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.

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.



[1] http://www.w3.org/TR/2011/WD-html5-20110525/apis-in-html-documents.html#dynamic-markup-insertion
[2] http://www.w3.org/TR/2011/WD-html5-20110525/history.html#unload-a-document
[3] http://www.w3.org/TR/2011/WD-html5-20110525/parsing.html#html-parser