Bug 13512 - Need a DOM event for AT to catch when content is inserted
Need a DOM event for AT to catch when content is inserted
Status: RESOLVED WORKSFORME
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec
unspecified
PC Windows NT
: P2 normal
: ---
Assigned To: Edward O'Connor
HTML WG Bugzilla archive list
: a11y, a11ytf
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-02 01:36 UTC by Cynthia Shelly
Modified: 2012-10-16 19:42 UTC (History)
13 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cynthia Shelly 2011-08-02 01:36:51 UTC
DOM-based AT relies on DOM mutation events to catch changes via innerHTML, outerHTML, insertAdjacentHTML.  This is slow and noisy.  It would be useful to have an event for these particular changes, since they so often signal new UI, dialog opening, etc. 

Assign back to a11y-TF for more info.
Comment 1 Tab Atkins Jr. 2011-08-02 03:03:27 UTC
This should be served by the new mutation events being discussed currently (I forget whether it's happening in htmlwg, whatwg, or webapps-wg).  You'll be able to better filter for the kinds of mutation events that you want to hear about, like element insertion.
Comment 2 Benjamin Hawkes-Lewis 2011-08-02 06:39:33 UTC
(In reply to comment #1)
> This should be served by the new mutation events being discussed currently (I
> forget whether it's happening in htmlwg, whatwg, or webapps-wg).

The Webapps WG are chartered to produce a new DOM events specification:

     http://www.w3.org/2008/webapps/charter/

     http://www.w3.org/TR/DOM-Level-3-Events/

They are actively discussing a replacement for mutation events, which they are proposing to deprecate:

     http://www.w3.org/2008/webapps/wiki/MutationReplacement
Comment 3 Michael[tm] Smith 2011-08-04 05:12:46 UTC
mass-move component to LC1
Comment 4 Ian 'Hixie' Hickson 2011-08-12 23:46:34 UTC
ATs shouldn't be based on JS APIs. That makes no sense.
Comment 5 Benjamin Hawkes-Lewis 2011-08-13 09:02:07 UTC
(In reply to comment #4)
> ATs shouldn't be based on JS APIs.

Some ATs are. Why shouldn't they be?

http://webanywhere.cs.washington.edu/wa.php

http://code.google.com/p/google-axsjax/
Comment 6 steve faulkner 2011-08-13 10:13:24 UTC
(In reply to comment #4)
> ATs shouldn't be based on JS APIs. That makes no sense.

isn't the AT that runs on your employers chrome OS?

"ChromeVox is built as a Chrome extension. This means that unlike most accessibility software, it is built using only web technologies like HTML5, CSS and Javascript."
http://googlecode.blogspot.com/2011/05/chromevox-built-in-spoken-feedback-for.html
Comment 7 Anne 2011-08-14 09:49:12 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>.

Status: Rejected
Change Description: no spec change
Rationale: This is out of scope for HTML. innerHTML and friends are moving out of HTML into DOM Parsing and mutation events will become part of DOM. I suggest contributing to the relevant threads on www-dom@w3.org and public-webapps@w3.org.
Comment 8 Cynthia Shelly 2012-01-05 16:45:03 UTC
Moving to WebApps for further discussion
Comment 9 Michael[tm] Smith 2012-01-13 02:07:17 UTC
(In reply to comment #8)
> Moving to WebApps for further discussion

It appears that this was re-moved back to HTML WG based on discussion on the a11y TF telcon:

http://www.w3.org/2012/01/12-html-a11y-minutes.html#item02

[[
Paul: WG isn't getting the notice when this is moved to another WG. People have complained when the editor has done this.
... Suggests creating a new bug to achieve this, not move an existing bug
... Same problem if component move, e.g. from LC to API component
]]
Comment 10 Ian 'Hixie' Hickson 2012-01-13 20:33:14 UTC
Ok well I didn't move it to another WG, Cynthia did. I just closed the bug. So, reassigning to Cynthia.
Comment 11 Edward O'Connor 2012-10-16 18:07:44 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: No spec change.
Rationale: This should be (and has been, AFAICT) addressed by a
combination of Mutation Events and the DOM Parsing and Serialization
specs, both of which are beeing worked in the WebApps WG. I encourage
interested parties to follow the work in those areas.
Comment 12 Edward O'Connor 2012-10-16 19:42:20 UTC
s/Mutation Events/Mutation Observers/, thanks Anne.