more bugs

In order from http://www.w3.org/WAI/PF/HTML/wiki/Spec_Review/All.  The ones with ** in front have questions for us to answer.

13509 mapping doc, no action
13510 mapping doc, no action
13511 document parsing should discuss setting up accessibility APIs
             Reopened with link to mapping doc https://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html
13654 -3.5.1 does unregistering event listeners include AT?
             Was wontfix.  Reopened and assigned to api mapping doc.
**13512 Need a DOM event for AT to catch when content is inserted
            Wontfix as out of scope, should be a bug against DOM spec not HTML.  Do we agree?
**13659 4.8.2 srcdoc seems error prone
Dup of 13599, which is rejected (but not won't fix?).  I don't really agree with the resolution, but it's not an accessibility bug, so  I'm inclined to let it go.  Any objections?
13660 not an accessibility bug.  Asked IE to look at it.
13661 4.8.2 Will iframe loading events break existing AT?
            Specd behavior is not a change from current behavior.  Marked verified.
**13662 Bug 13662 -will the sandbox attribute break script-based AT?
            Leaning towards verify.  I'm checking with a few people about whether the answer is correct.
13663 mapping doc, no action
13664 -what events are fired when iframe seemless attribute is changed dynamically?
                Reopened and assigned to api mapping doc
13453 Scaling of images and image maps
      Fixed
**13656 add examples of use of input, button, select etc. outside of form element
        NEED HELP to find examples of <input>, <select> etc. used outside of <form> in web apps.  Anyone have some good sites?
**13528 Many examples in the forms section to do not exemplify best practice
    Verified invalid.  Specific bugs below replace this meta bug.
13530 example in 4.10.1 has unneeded <p> around form elements
      Verified.  While I think this is not great coding practice, it's considered a style issue.  Not worth fighting.
**13531 -use of implicit labels in examples
     Do we want to fight for examples using only explicit <label for> labels, or let stand examples of implicit lables?
**13542 example in 4.10.1 uses should use <input type=submit> or <button type=submit>
    Do we want to fight for example to use the most semantically correct button?  The example probably works fine, but is not exemplary practice.
13543 -add examples of use of fieldset and legend for non-interactive forms.
   Verified fixed.  Yay.

13553 4.10.6 confusing, seemlingly contradictory text
   Do we want to fight to remove or rewrite this confusing text?  Can someone suggest edits?
"The label<http://dev.w3.org/html5/spec/forms.html#the-label-element> element's exact default presentation and behavior, in particular what its behavior<http://dev.w3.org/html5/spec/content-models.html#activation-behavioractivation> might be, if anything, should match the platform's label behavior. The activation behavior<http://dev.w3.org/html5/spec/content-models.html#activation-behavior> of a label<http://dev.w3.org/html5/spec/forms.html#the-label-element> element for events targetted at interactive content<http://dev.w3.org/html5/spec/content-models.html#interactive-content> descendants of a label<http://dev.w3.org/html5/spec/forms.html#the-label-element> element, and any descendants of those interactive content<http://dev.w3.org/html5/spec/content-models.html#interactive-content> descendants, must be to do nothing."

>From the bug comment
Rationale: The sentence is question is required to make sure that if you click
on a text field inside a <label> whose labeled control is another text field,
you don't end up focusing the other text field (which would be rather confusing
to users).

13547 overloading of input element is confusing
     Verified won't fix.  I would like to consider this for HTML.next.  Not sure how to do that

**13548 size, width and height attributes on input should be conforming but obsolete
   I'm inclined to accept this won't fix.  Anyone want to fight it?

**13549 4.10.18 associating form elements with forms that do not contain them can cause navigation problems for AT and keyboard users

   Reopened with the text below,  I expect a fight on this.
screen reader users do know what the DOM order is, because screen readers present content in DOM order, not visual order.  So, these use cases will become confusing for these users.

Similarly, tab order is based on DOM order.  It can be adjusted with incrementing tabindexes, but that is a strategy that is well known to get broken over time, and also difficult to implement in dynamic and composited sites.

Wouldn't it make sense in the use cases below to just use one big form, around all the elements?  This feature seems to encourage overly complex and inaccessible authoring practices, when we should be developing techniques to avoid that.

Can you link to some examples of those use cases, so we can see if there is a way to build them accessibly, and build them without this feature?

*** NEED HELP to dig up some use cases and rewrite them accessibly without this feature.  These are the use cases Ian mentioned:
Rationale: The use case is situations like tables where each column or each row
contains a different form, and cases where a page-long form contains inside it
a separate unrelated form (e.g. a tax form with a little calculator on the side
to help work out some component of the bigger form).

13550 see earlier mail
13551 see earlier mail

**13552 confusing, seemingly contradictory text in 4.10.7
    this is weird.  My first comment with details of the bug seems to have disappeared???  Can any bugzilla wizards help figure out why?  Do we want to fight for editorial changes on unclear text?

13554 4.10.7 please specify all cases where readonly attribute makes the input immutable
  Verified worksforme.  Content was elsewhere in the spec.

**13560 dynamic changes to input type attribute may cause problems for accessibility APIs
   We need to discuss this.  Can we put it on an agenda for early January?

**13559 <input type=email multiple> should support splitting on ";" as well as ","
  I'm talking to people who might use this feature about how much this impacts them to decide about accepting the won't fix.  Will it cause them to use type=text instead of email, losing semantic info.

More to come...