This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10066 - replace section 3.2.6 with the alternative spec text provided (ARIA)
Summary: replace section 3.2.6 with the alternative spec text provided (ARIA)
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P1 major
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf, aria, NE, WGDecision
: 11798 (view as bug list)
Depends on: 8000 9817 10438 10439 10440 10441 10444 10445 10446 10447 10448 10449 10450 10451 10452 10462 10463 10464 10465 10467 10478 10479 10481 10485 10486 10487 10493 10494 10496 10591 10592 10593 10594 10600 10603 10614 10618 10903 10905 10914 10919 12590 23611 23616
Blocks: 10484 10495 10497
  Show dependency treegraph
 
Reported: 2010-07-02 13:58 UTC by steve faulkner
Modified: 2013-10-23 20:08 UTC (History)
17 users (show)

See Also:


Attachments
Current ARIA mappings as a text file (6.95 KB, text/plain)
2010-07-28 04:57 UTC, Maciej Stachowiak
Details
Proposed ARIA mappings as a text file (8.46 KB, text/plain)
2010-07-28 04:57 UTC, Maciej Stachowiak
Details
diff from current ARIA mappings to proposed (12.30 KB, patch)
2010-07-28 04:58 UTC, Maciej Stachowiak
Details
Proposed ARIA mappings as a text file (sorted properly) (8.46 KB, text/plain)
2010-07-28 04:59 UTC, Maciej Stachowiak
Details
diff from current ARIA mappings to proposed (based on proper sort) (11.60 KB, patch)
2010-07-28 05:00 UTC, Maciej Stachowiak
Details
Current spec ARIA mappings v3 (6.97 KB, text/plain)
2010-07-28 05:20 UTC, Maciej Stachowiak
Details
Proposed new ARIA mappings v3 (8.74 KB, text/plain)
2010-07-28 05:20 UTC, Maciej Stachowiak
Details
ARIA mapping changes as a diff v3 (11.61 KB, patch)
2010-07-28 05:21 UTC, Maciej Stachowiak
Details
ARIA changes diff in readable HTML form (51.72 KB, text/html)
2010-07-28 05:21 UTC, Maciej Stachowiak
Details
diff for review (21.41 KB, patch)
2011-04-11 23:55 UTC, Ian 'Hixie' Hickson
Details

Description steve faulkner 2010-07-02 13:58:16 UTC
The A11y taskforce WAI-ARIA mapping sub team has reviewed the current specification text (3.2.6 Annotations for assistive technology products (ARIA)) and found it to be wholey unsuitable as a starting point for review as its intent is to promote punishing authors for authoring practices deemed non conforming (http://dev.w3.org/html5/spec/elements.html#semantics-0) in the specification by targeting authors who apply the declarative accessibility API semantics (WAI-ARIA) to produce accessible web content. As it is not possible to otherwise determine, in all instances, that an author has used script and CSS to re-purpose HTML elements in a way that is inconsistent with their semantic intent this will have the adverse and damaging effect of reducing the accessibility of web content, the use of WAI-ARIA, and the utility of conformance checkers. It is a fact that authors have use script and CSS to re-purpose web content to meet their needs and the tools that allow them to do so, script and CSS, are still fully supported in HTML5. Therefore, it essential that this section be rewritten to allow the use of WAI-ARIA wherever the author needs unless doing so adversely impacts the conveyance of accessibility information by the user agent to the assistive technology.
 
We have carried an almost complete rewrite of '3.2.6 Annotations for assistive technology products (ARIA)' and request that current section '3.2.6, Annotations for assistive technology products (ARIA)' http://dev.w3.org/html5/spec/embedded-content-0.html#annotations-for-assistive-technology-products-aria, be replaced with a new section '3.2.6, Use of WAI-ARIA Roles, States and Properties in HTML' http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html, which can then be used for the basis of further review and discussion by the W3C HTML working group.
Comment 1 Maciej Stachowiak 2010-07-21 01:57:16 UTC
The Chairs would like to request expedited resolution for this bug, since settling the issue of ARIA mappings will potentially be an outlier for the WG.
Comment 2 Maciej Stachowiak 2010-07-28 04:57:05 UTC
Created attachment 895 [details]
Current ARIA mappings as a text file

These are the current ARIA mappings in the spec. The format is:

element | default role/properties | allowed roles
Comment 3 Maciej Stachowiak 2010-07-28 04:57:36 UTC
Created attachment 896 [details]
Proposed ARIA mappings as a text file
Comment 4 Maciej Stachowiak 2010-07-28 04:58:08 UTC
Created attachment 897 [details]
diff from current ARIA mappings to proposed
Comment 5 Maciej Stachowiak 2010-07-28 04:59:23 UTC
Created attachment 898 [details]
Proposed ARIA mappings as a text file (sorted properly)
Comment 6 Maciej Stachowiak 2010-07-28 05:00:00 UTC
Created attachment 899 [details]
diff from current ARIA mappings to proposed (based on proper sort)
Comment 7 Maciej Stachowiak 2010-07-28 05:20:35 UTC
Created attachment 900 [details]
Current spec ARIA mappings v3
Comment 8 Maciej Stachowiak 2010-07-28 05:20:53 UTC
Created attachment 901 [details]
Proposed new ARIA mappings v3
Comment 9 Maciej Stachowiak 2010-07-28 05:21:16 UTC
Created attachment 902 [details]
ARIA mapping changes as a diff v3
Comment 10 Maciej Stachowiak 2010-07-28 05:21:35 UTC
Created attachment 903 [details]
ARIA changes diff in readable HTML form
Comment 11 steve faulkner 2010-08-19 21:11:39 UTC
As per HTML Accessibility Task force Action-55 - http://www.w3.org/2010/08/19-html-a11y-minutes.html#action02

Draft text:  3.2.6 Use of WAI-ARIA Roles, States and Properties in HTML
http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html

Change Proposal: 
ARIA in HTML5: replace current text of section 3.2.6
http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5
Comment 12 Maciej Stachowiak 2010-08-22 02:41:23 UTC
When I produced the diffs attached to this bug, I found that they fall into the following categories:


1) Use of some ARIA property attributes is restricted when a related native HTML attribute is present.

2) Some elements that previously had no default role and allowed any role simply because the spec did not say otherwise, are now explicitly documented as allowing any role. Oddly, some remain undocumented though.

3) Some elements have much less restrictive sets of allowed roles in the proposal than in the current draft. In some cases (e.g. <a role=button>) it's clear how this relates to the rationale based on actual author usage practices. In other cases (e.g. <a role=scrollbar>, <input type=checkbox role=radio>), it's not obvious without further explanation how that rationale applies. Are these things that authors really do? If so, are there examples that can be cited? I don't think I have ever seen an <a> element used as a scrollbar or a slider myself, and I've seen a lot of crazy markup.

4) Some elements have a more restrictive set of allowed roles and/or new default roles. For example, embed allows any role in the current draft, but in the proposal is limited to no role, application, document or image. As another example, keygen is now not allowed to take any role at all.

5) Some elements are about equally restrictive but just different. For example <menu type=context> changing from no role to "menu".


I also noticed the following notable details in the changes:

1) Element default roles that are not explicitly documented in the proposal.

The proposed new ARIA section explicitly lists most of the elements which have no role by default and can be given any role. However, it seems to have missed the following:

a (that does not represent a hyperlink)
area (that does not represent a hyperlink)
caption
command
dd
dl
dt
h1-h6 (with an hgroup ancestor)
img (that does not have an empty alt)
li (with no ol or ul parent)
optgroup
option (not in list of options or datalist)

2) Elements that have their default role changed

These differences seem more individually notable than the others, and may be oversights in either the current spec or the proposal. They might be worth extra attention.

details - changed from no role to "button" role
input type=file - changed from "button" role to no role
link (that represents a hyperlink) - changed from "link" role to no role
menu type=context - changed from no role to "menu" role
output - changed from "status" role to no role
math - changed from no role to "math" role
table - changed from "grid" role to no role
td - changed from "gridcell" role to no role
tr - changed from "row" role to no role
Comment 13 steve faulkner 2010-08-22 05:24:24 UTC
Maciej wrote:

> a (that does not represent a hyperlink)
> area (that does not represent a hyperlink)
> caption
> command
> dd
> dl
> dt
> h1-h6 (with an hgroup ancestor)
> img (that does not have an empty alt)
> li (with no ol or ul parent)
> optgroup
> option (not in list of options or datalist)

all of these are in the latest draft except "option (not in list of options or datalist)" as I could not find where the option element can be used in circumstances other than in a  list of options or a datalist,





(In reply to comment #12)
> When I produced the diffs attached to this bug, I found that they fall into the
> following categories:
> 
> 
> 1) Use of some ARIA property attributes is restricted when a related native
> HTML attribute is present.
> 
> 2) Some elements that previously had no default role and allowed any role
> simply because the spec did not say otherwise, are now explicitly documented as
> allowing any role. Oddly, some remain undocumented though.
> 
> 3) Some elements have much less restrictive sets of allowed roles in the
> proposal than in the current draft. In some cases (e.g. <a role=button>) it's
> clear how this relates to the rationale based on actual author usage practices.
> In other cases (e.g. <a role=scrollbar>, <input type=checkbox role=radio>),
> it's not obvious without further explanation how that rationale applies. Are
> these things that authors really do? If so, are there examples that can be
> cited? I don't think I have ever seen an <a> element used as a scrollbar or a
> slider myself, and I've seen a lot of crazy markup.
> 
> 4) Some elements have a more restrictive set of allowed roles and/or new
> default roles. For example, embed allows any role in the current draft, but in
> the proposal is limited to no role, application, document or image. As another
> example, keygen is now not allowed to take any role at all.
> 
> 5) Some elements are about equally restrictive but just different. For example
> <menu type=context> changing from no role to "menu".
> 
> 
> I also noticed the following notable details in the changes:
> 
> 1) Element default roles that are not explicitly documented in the proposal.
> 
> The proposed new ARIA section explicitly lists most of the elements which have
> no role by default and can be given any role. However, it seems to have missed
> the following:
> 
> a (that does not represent a hyperlink)
> area (that does not represent a hyperlink)
> caption
> command
> dd
> dl
> dt
> h1-h6 (with an hgroup ancestor)
> img (that does not have an empty alt)
> li (with no ol or ul parent)
> optgroup
> option (not in list of options or datalist)
> 
> 2) Elements that have their default role changed
> 
> These differences seem more individually notable than the others, and may be
> oversights in either the current spec or the proposal. They might be worth
> extra attention.
> 
> details - changed from no role to "button" role
> input type=file - changed from "button" role to no role
> link (that represents a hyperlink) - changed from "link" role to no role
> menu type=context - changed from no role to "menu" role
> output - changed from "status" role to no role
> math - changed from no role to "math" role
> table - changed from "grid" role to no role
> td - changed from "gridcell" role to no role
> tr - changed from "row" role to no role
Comment 14 steve faulkner 2010-08-22 06:45:48 UTC
maciej wrote:


> 2) Elements that have their default role changed
> 
> These differences seem more individually notable than the others, and may be
> oversights in either the current spec or the proposal. They might be worth
> extra attention.
> 


> details - changed from no role to "button" role

from reading the spec we concluded that details may have a default role of button as it is likely to be the element a user will interact with to show/hide the details content.


> input type=file - changed from "button" role to no role

in the majority of cases this is a composite control consisting of a button and a text box. refer to www.456bereastreet.com/archive/200410/styling_even_more_form_controls/ for example browser rendering of this control.


> link (that represents a hyperlink) - changed from "link" role to no role

as it is one of the meta elements and not generally included as part of the page content we consider it to be out of scope for ARIA.


> menu type=context - changed from no role to "menu" role
its a menu

> output - changed from "status" role to no role
its not a role=status its may be a generalised live region.

> math - changed from no role to "math" role

role="math" will map to a math role in Accessibility APIs (if they have one) We think the <math> element will also be mapped to a math role in APIs

> table - changed from "grid" role to no role
 role="grid" is an interactive table, a table by default is not interactive.

> td - changed from "gridcell" role to no role
role="gridcell" is an interactive cell, a cell by default is not interactive.

> tr - changed from "row" role to no role

"Rows contain gridcell elements, and thus serve to organize the grid."
http://www.w3.org/WAI/PF/aria/roles#row



(In reply to comment #12)
> When I produced the diffs attached to this bug, I found that they fall into the
> following categories:
> 
> 
> 1) Use of some ARIA property attributes is restricted when a related native
> HTML attribute is present.
> 
> 2) Some elements that previously had no default role and allowed any role
> simply because the spec did not say otherwise, are now explicitly documented as
> allowing any role. Oddly, some remain undocumented though.
> 
> 3) Some elements have much less restrictive sets of allowed roles in the
> proposal than in the current draft. In some cases (e.g. <a role=button>) it's
> clear how this relates to the rationale based on actual author usage practices.
> In other cases (e.g. <a role=scrollbar>, <input type=checkbox role=radio>),
> it's not obvious without further explanation how that rationale applies. Are
> these things that authors really do? If so, are there examples that can be
> cited? I don't think I have ever seen an <a> element used as a scrollbar or a
> slider myself, and I've seen a lot of crazy markup.
> 
> 4) Some elements have a more restrictive set of allowed roles and/or new
> default roles. For example, embed allows any role in the current draft, but in
> the proposal is limited to no role, application, document or image. As another
> example, keygen is now not allowed to take any role at all.
> 
> 5) Some elements are about equally restrictive but just different. For example
> <menu type=context> changing from no role to "menu".
> 
> 
> I also noticed the following notable details in the changes:
> 
> 1) Element default roles that are not explicitly documented in the proposal.
> 
> The proposed new ARIA section explicitly lists most of the elements which have
> no role by default and can be given any role. However, it seems to have missed
> the following:
> 
> a (that does not represent a hyperlink)
> area (that does not represent a hyperlink)
> caption
> command
> dd
> dl
> dt
> h1-h6 (with an hgroup ancestor)
> img (that does not have an empty alt)
> li (with no ol or ul parent)
> optgroup
> option (not in list of options or datalist)
> 
> 2) Elements that have their default role changed
> 
> These differences seem more individually notable than the others, and may be
> oversights in either the current spec or the proposal. They might be worth
> extra attention.
> 
> details - changed from no role to "button" role
> input type=file - changed from "button" role to no role
> link (that represents a hyperlink) - changed from "link" role to no role
> menu type=context - changed from no role to "menu" role
> output - changed from "status" role to no role
> math - changed from no role to "math" role
> table - changed from "grid" role to no role
> td - changed from "gridcell" role to no role
> tr - changed from "row" role to no role
Comment 15 Maciej Stachowiak 2010-08-22 12:59:35 UTC
Thanks, Steve, your comments here are very helpful. I believe the bug should be ready for action by the editor now. I have comments on just one of these:

(In reply to comment #14)
> 
> 
> > details - changed from no role to "button" role
> 
> from reading the spec we concluded that details may have a default role of
> button as it is likely to be the element a user will interact with to show/hide
> the details content.

That doesn't seem quite right to me. <details> is intended to be presented much like a "disclosure triangle" control on Mac OS X, it includes an affordance indicating the presence of details, the label inside the <summary> element, and the actual details content. I don't think this acts like a button - most of it (the details part) will not even react to clicks. I don't think there is an appropriate ARIA role for this whole element, although it could be presented via assistive technologies as a compound control which among other things includes a button.
Comment 16 steve faulkner 2010-08-22 14:52:07 UTC
Hi Maciej, 

you wrote:
> That doesn't seem quite right to me. <details> is intended to be presented much

note that we are also unsure about this
in the revised spec text table under details it states:

"details element * may change based on resolution of bug 9817" [http://www.w3.org/Bugs/Public/show_bug.cgi?id=9817]

Note: default mappings indicated in the table are not meant to be advice for implementors.



(In reply to comment #15)
> Thanks, Steve, your comments here are very helpful. I believe the bug should be
> ready for action by the editor now. I have comments on just one of these:
> (In reply to comment #14)
> > 
> > 
> > > details - changed from no role to "button" role
> > 
> > from reading the spec we concluded that details may have a default role of
> > button as it is likely to be the element a user will interact with to show/hide
> > the details content.
> That doesn't seem quite right to me. <details> is intended to be presented much
> like a "disclosure triangle" control on Mac OS X, it includes an affordance
> indicating the presence of details, the label inside the <summary> element, and
> the actual details content. I don't think this acts like a button - most of it
> (the details part) will not even react to clicks. I don't think there is an
> appropriate ARIA role for this whole element, although it could be presented
> via assistive technologies as a compound control which among other things
> includes a button.
Comment 17 Ian 'Hixie' Hickson 2010-08-23 21:29:22 UTC
Can we please restrict this to one issue per bug?

Please file actual separate bugs for each problem with the current spec. I really don't even know where to begin with this bug.
Comment 18 Maciej Stachowiak 2010-08-26 03:31:37 UTC
I filed a few more specific bugs (still working on this):

<input type=file> default role: bug 10439
<link> default role: bug 10441
<menu type=context> default role: bug 10440
<math> default role: bug 10438

No bugs yet on details, output, table, td or tr, because I'm not entirely clear on the explanations for those (queries sent).
Comment 19 Maciej Stachowiak 2010-08-26 09:37:36 UTC
Elements with no default role are unlisted:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10444
Comment 20 Maciej Stachowiak 2010-08-26 10:29:15 UTC
Elements that should have no role as a strong semantic:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10445

Role limitations for media and embedding elements:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10446

Give <output> no role by default instead of status:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10447

Extended roles for command elements
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10448

Extended roles for h1-h6:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10449

Extended roles for list elements:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10450

Limit label roles:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10451

Separate table for ARIA properties:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10452
Comment 21 Ian 'Hixie' Hickson 2010-08-26 18:52:58 UTC
Thanks Maciej. I'm reassigning this bug to you for tracking purposes and will deal with the bugs you filed directly.
Comment 22 Leif Halvard Silli 2010-08-28 19:00:29 UTC
Maciej, 

Your ARIA tables does not reflect the A11Y TF proposal when it comes to the IMG element.

The proposal  (http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html) from the A11Y TF says that the _default_ for IMG element should be role="img". 

Whereas you in your summary (http://www.w3.org/Bugs/Public/attachment.cgi?id=901) of the ARIA proposal claims that the A11Y TF wants the default to be "no role".

Because of this, bug 10444 was not solved correctly.
Comment 23 Michael Cooper 2010-08-31 13:31:18 UTC
http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0013.html

The bug triage sub-team recommends the accessibility task force follow this.
Comment 24 steve faulkner 2010-09-02 14:03:34 UTC
Have updated spec text to reflect agreement on various bugs:
http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html

have added a reference to HTML to Platform Accessibility APIs Implementation Guide http://www.paciellogroup.com/blog/misc/HTML5/HTML-API-MAPPING.html

have updated aria-html5 attribute mapping table
Comment 25 Leif Halvard Silli 2010-09-03 03:21:02 UTC
(In reply to comment #0)

> be replaced with a new section '3.2.6, Use of WAI-ARIA Roles, States and
> Properties in HTML'
> http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html

Steve, I don't know where to track this ..

but the first table in your replacement draft says about the <map> element that it may take "any role, any widget , live region, drag & drop and relationship attributes". 

While bottom of the document says that "Conformance checkers may provide error messages when the role attribute or any aria-* attributes are used on the  [...snip...]  map [...snip...] elements.
Comment 26 steve faulkner 2010-09-03 07:49:33 UTC
(In reply to comment #25)
> (In reply to comment #0)
> > be replaced with a new section '3.2.6, Use of WAI-ARIA Roles, States and
> > Properties in HTML'
> > http://www.paciellogroup.com/blog/misc/HTML5/aria-html5-proposal.html
> Steve, I don't know where to track this ..
> but the first table in your replacement draft says about the <map> element that
> it may take "any role, any widget , live region, drag & drop and relationship
> attributes". 
> While bottom of the document says that "Conformance checkers may provide error
> messages when the role attribute or any aria-* attributes are used on the 
> [...snip...]  map [...snip...] elements.

Hi Leif, have fixed it, thanks for poitning it out.
Comment 27 steve faulkner 2010-09-10 14:52:11 UTC
added bug 10481 as a dependent
Comment 28 Ian 'Hixie' Hickson 2010-11-11 23:05:59 UTC
Closing on the advice of the chairs since there is now a tracker issue for this topic.
Comment 29 Martin Kliehm 2010-11-30 12:38:49 UTC
Has been escalated in ISSUE 129
Comment 30 Michael Cooper 2011-01-25 16:36:24 UTC
*** Bug 11798 has been marked as a duplicate of this bug. ***
Comment 31 Sam Ruby 2011-03-01 14:51:25 UTC
Per 
http://lists.w3.org/Archives/Public/public-html/2011Mar/0005.html :

The HTML Working Group hereby adopts the ARIA in HTML5: change some role mappings Proposal for ISSUE-129, with some specific exclusions.  Of the Change Proposals before us, this one has drawn the weaker objections.

http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5

The specific exclusions are:

   * Any changes to how <hgroup> elements are to be interpreted, or how
     headings contained within such an <hgroup> are to be interpreted.
   * Allowing slider, scrollbar, or progressbar for <button>, <input
     type=image>, or <input type=image>
   * Allowing progressbar, radio, slider, or scrollbar for <a>
   * Allowing button, checkbox, option, radio, slider, spinbutton, or
     scrollbar on <h1>-<h6>

Please execute the remaining edits specified in the Change Proposal.
Comment 32 steve faulkner 2011-03-02 23:02:15 UTC
(In reply to comment #31)
> Per 
> http://lists.w3.org/Archives/Public/public-html/2011Mar/0005.html :
> 
> The HTML Working Group hereby adopts the ARIA in HTML5: change some role
> mappings Proposal for ISSUE-129, with some specific exclusions.  Of the Change
> Proposals before us, this one has drawn the weaker objections.
> 
> http://www.w3.org/html/wg/wiki/ChangeProposals/ARIAinHTML5
> 
> The specific exclusions are:
> 
>    * Any changes to how <hgroup> elements are to be interpreted, or how
>      headings contained within such an <hgroup> are to be interpreted.
>    * Allowing slider, scrollbar, or progressbar for <button>, <input
>      type=image>, or <input type=image>
>    * Allowing progressbar, radio, slider, or scrollbar for <a>
>    * Allowing button, checkbox, option, radio, slider, spinbutton, or
>      scrollbar on <h1>-<h6>
> 
> Please execute the remaining edits specified in the Change Proposal.

have provided a set of required additions and deletions:
http://lists.w3.org/Archives/Public/public-html/2011Mar/0067.html
http://lists.w3.org/Archives/Public/public-html/2011Mar/0068.html
Comment 33 Ian 'Hixie' Hickson 2011-04-08 22:34:29 UTC
If I understand correctly, the change proposal's details section requests the following changes:
-------------------------
button element, input type="image", input type=button:	allowed roles: button, link, menuitem, menuitemcheckbox, menuitemradio,presentation, radio, slider, scrollbar or progressbar.
h1 to h6 element that does have an hgroup ancestor: The first h1 to h6 element element with the highest ranking (1-6) has a heading role with the aria-level property set to the element's ranking . Any other h1 to h6 element elements have no default role. OR leave defaulkt heading semantics unchanged and provide advic to user agents on how to present the semantics of the heading/subheading.
hgroup element: no default role
a element that represents a hyperlink allowed roles: button, checkbox, link, menuitem, menuitemcheckbox, menuitemradio, presentation, progressbar, radio, slider, scrollbar, tab, or treeitem.
img element that does not have an empty alt attribute: default role of img. allowed roles: any
H1 to H6 allowed roles: button, checkbox, link, menuitem, menuitemcheckbox, menuitemradio, option, presentation, radio, slider, spinbutton, scrollbar, tab or treeitem.
-------------------------

The exclusions are:
-------------------------
Any changes to how <hgroup> elements are to be interpreted, or how headings contained within such an <hgroup> are to be interpreted.
Allowing slider, scrollbar, or progressbar for <button>, <input type=image>, or <input type=image>
Allowing progressbar, radio, slider, or scrollbar for <a>
Allowing button, checkbox, option, radio, slider, spinbutton, or scrollbar on <h1>-<h6>
-------------------------
I assume the first "image" of this should be "button".

The resulting requested changes, if I'm not mistaken, are thus as follows (I've removed 'presentation' from these lists since it's already always allowed):
-------------------------
button element, input type="image", input type=button:	allowed roles: button, link, menuitem, menuitemcheckbox, menuitemradio, radio.
a element that represents a hyperlink allowed roles: button, checkbox, link, menuitem, menuitemcheckbox, menuitemradio, tab, or treeitem.
img element that does not have an empty alt attribute: default role of img. allowed roles: any
H1 to H6 allowed roles: link, menuitem, menuitemcheckbox, menuitemradio, tab or treeitem.
-------------------------
Comment 34 steve faulkner 2011-04-09 12:54:55 UTC
(In reply to comment #33)
> If I understand correctly, the change proposal's details section requests the
> following changes:
> -------------------------
> button element, input type="image", input type=button:    allowed roles:
> button, link, menuitem, menuitemcheckbox, menuitemradio,presentation, radio,
> slider, scrollbar or progressbar.
> h1 to h6 element that does have an hgroup ancestor: The first h1 to h6 element
> element with the highest ranking (1-6) has a heading role with the aria-level
> property set to the element's ranking . Any other h1 to h6 element elements
> have no default role. OR leave defaulkt heading semantics unchanged and provide
> advic to user agents on how to present the semantics of the heading/subheading.
> hgroup element: no default role
> a element that represents a hyperlink allowed roles: button, checkbox, link,
> menuitem, menuitemcheckbox, menuitemradio, presentation, progressbar, radio,
> slider, scrollbar, tab, or treeitem.
> img element that does not have an empty alt attribute: default role of img.
> allowed roles: any
> H1 to H6 allowed roles: button, checkbox, link, menuitem, menuitemcheckbox,
> menuitemradio, option, presentation, radio, slider, spinbutton, scrollbar, tab
> or treeitem.
> -------------------------
> 
> The exclusions are:
> -------------------------
> Any changes to how <hgroup> elements are to be interpreted, or how headings
> contained within such an <hgroup> are to be interpreted.
> Allowing slider, scrollbar, or progressbar for <button>, <input type=image>, or
> <input type=image>
> Allowing progressbar, radio, slider, or scrollbar for <a>
> Allowing button, checkbox, option, radio, slider, spinbutton, or scrollbar on
> <h1>-<h6>
> -------------------------
> I assume the first "image" of this should be "button".
> 
> The resulting requested changes, if I'm not mistaken, are thus as follows (I've
> removed 'presentation' from these lists since it's already always allowed):
> -------------------------
> button element, input type="image", input type=button:    allowed roles:
> button, link, menuitem, menuitemcheckbox, menuitemradio, radio.
> a element that represents a hyperlink allowed roles: button, checkbox, link,
> menuitem, menuitemcheckbox, menuitemradio, tab, or treeitem.
> img element that does not have an empty alt attribute: default role of img.
> allowed roles: any
> H1 to H6 allowed roles: link, menuitem, menuitemcheckbox, menuitemradio, tab or
> treeitem.
> -------------------------


the spec text for headings h1-h6 is incorrect, there was never any intention in the change proposal to remove the default mapping for heading or make a restriction on headings having a role of heading with the apropriate oultine level.

As pointed out several times the changes for headings are clearly marked in the spec text provided:
http://www.html5accessibility.com/tests/aria-changes.html

change what you have currently put in to reflect what was intended.
Comment 35 Ian 'Hixie' Hickson 2011-04-10 17:14:38 UTC
The change described in the change proposal as modified by the decision is checked in.
Comment 36 Ian 'Hixie' Hickson 2011-04-11 23:37:41 UTC
reverted change per http://lists.w3.org/Archives/Public/public-html/2011Apr/0272.html
Comment 37 Ian 'Hixie' Hickson 2011-04-11 23:55:19 UTC
Created attachment 976 [details]
diff for review

As requested by http://lists.w3.org/Archives/Public/public-html/2011Apr/0272.html.
As far as I am aware, this is an exact application of the WG decision.
Comment 38 Sam Ruby 2011-04-15 08:20:58 UTC
(In reply to comment #37)
> Created attachment 976 [details]
> diff for review
> 
> As requested by
> http://lists.w3.org/Archives/Public/public-html/2011Apr/0272.html.
> As far as I am aware, this is an exact application of the WG decision.

Steven Faulkner has asked on public-html[1][2][3]:

> I ask Ian to add 'heading' to the allowable roles as allowing it
> is consistent with all other elements that have a default role.

> and If Ian will not agree it would be appreciated if he can provide a
> clear technical reason for not doing so.

[1] http://lists.w3.org/Archives/Public/public-html/2011Apr/0378.html
[2] http://lists.w3.org/Archives/Public/public-html/2011Apr/0402.html
[3] http://lists.w3.org/Archives/Public/public-html/2011Apr/0404.html
Comment 39 Ian 'Hixie' Hickson 2011-04-15 20:18:55 UTC
I would much rather apply the decision as written and apply fixes separately.
Comment 40 steve faulkner 2011-04-15 20:53:05 UTC
(In reply to comment #39)
> I would much rather apply the decision as written and apply fixes separately.

So is there a technical reason for not wanting to add the role? or are you just playing games?
Comment 41 Maciej Stachowiak 2011-04-23 03:46:36 UTC
(In reply to comment #39)
> I would much rather apply the decision as written and apply fixes separately.

The diff for review has been confirmed as acceptable.