RE: more bugs

And more.  I think this covers all of my bugs.
Those with ** need to be discussed on a call.

13558 added comment to bug about whether the friendly name gets stored

**13561 not having details on this is by design.  The idea is that UA should decide how to render it.  Personally, I think this design is bad for accessibility as it will lead to inconsistent implementation.  However, it's a pretty core idea for a lot of people on the WG.  We need to decide how bad it is, and if we want to fight this issue in general.

13657 covered in earlier mail

**13562 another one where exact controls are unspecified by design (like 13561).

13563 dup of 10710 verified

**13566 use of input type image to send coordinates should be phased out
Ian will add more non-normative text to discourage this.  Do we want to push for  obsolete but conforming, or provide text?  Can obc be made to work in this scenario?

13567 Fix typos in definition of <input type=image alt="">
Proposed changes look fine to me

13568 use of "accessible" to refer to placement of UI controls is confusing
Fixed and verified

13569 Allow user agents to override autocomplete
Ian points out that this is already a should, not a must.  Verified won't fix

13570 -why does input type=color support autocomplete?
I'm having a hard time understanding how the UI would work for this in a color picker.  If type=color is rendered as a text field, it would have a dropdown for autocomplete, like any other text field.  But if it is rendered as a color picker, what would the autocomplete look like?  Maybe just say that the autocomplete is only used if type=color is rendered as a text box?

13571 -user agent MUST allow user to activate the button
Reopened with the following comment
Can you list the other cases (besides being disabled) where the button can't be activated, so this can be a must?  Being activated is the point of buttons, and non-activatable buttons will be a problem for AT and for users with cognitive issues.

13572 -4.10.19 aborting autofocus based on user choice not optional
Reopened with this comment
"8.If the user has indicated (for example, by starting to type in a form
control) that he does not wish focus to be changed, then optionally abort these
steps."

Can we remove the word "optionally"?


**Finally, there is discussion of the lack of a 3-state checkbox, but no bug filed.  Is there a different bug on this?


From: Cynthia Shelly [mailto:cyns@microsoft.com]
Sent: Friday, December 23, 2011 11:36 AM
To: public-html-a11y@w3.org
Subject: 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...