Re: changes to headings in ARIA in HTML5

Hi Ian,

>The changes you describe are quite clearly not at all an occurate
>portrayal of the decision, since there are changes listed there that are
>not listed in the change proposal at all. For example, your document has
>all manner of changes relating to tables, which are not even mentioned in
>the change proposal or the decision. Plus, regarding headings
>specifically, your table suggests that authors should be required to apply
>an aria-level="" property to every heading, which is just absurd.

In the email I sent to public html and you on the 2nd of march[1] it states:

"NOTE: the deletion of the rows in the data tables pertaining to the table,
tr, td and th elemnts is NOT part of the change proposal, but were removed
earlier by the html5 editor and NO agreement on re-inserting them has
occured, but have mysteriously re-appeared in this version of the spec, so
need to be removed once again"

feel free to ignore those portions relating to tables I can raise them as a
seperate issue.

>regarding headings
>specifically, your table suggests that authors should be required to apply
>an aria-level="" property to every heading, which is just absurd.

I am unclear on how you reached this conclusion, but if there is spec text
you think can clarify that this is not the case, feel free to suggest it to
the list or submit a last call bug.

>Given that the decision has all manner of what I consider mistakes (e.g.
>it is inconsistent about whether menuitemradio and radio vs
>menuitemcheckbox and checkbox should apply at the same time, it gives
>different allowed roles for <area> and <a>, it has the quite ludicrous
>decision of allowing buttons to be exposed as links and radio buttons, and
>it even allows a heading to be made into a treeitem, not to mention the
>issue above regarding not allowing headings to be marked as headings)


given that ANY HTML element can be turned into a menu item by the addition
of an accesskey attribute and placement in a menu [2]:

"An element that defines a
command<http://dev.w3.org/html5/spec/Overview.html#concept-command>,
whose Type <http://dev.w3.org/html5/spec/Overview.html#command-facet-type>facet
is "command", and that is a descendant of a
menu <http://dev.w3.org/html5/spec/Overview.html#menus> element whose
type<http://dev.w3.org/html5/spec/Overview.html#attr-menu-type>attribute
in the
list <http://dev.w3.org/html5/spec/Overview.html#list-state> state "

so this is conforming:

<menu type="list">
<h1 accesskey=1>menutiem</h1>
<h1 accesskey=2>menutiem</h1>
<h1 accesskey=3>menutiem</h1>
</menu>

I am unclear about you apparent concern.

"it even allows a heading to be made into a treeitem"

adding a role="foo" to an element DOES NOT make it into a foo. DEVELOPERS
MAKE <bar> into <foo> by adding scripting and CSS.
All adding a role does is provide an indication to AT that <bar> is not
being used as <bar> but as <foo>. Thus providing the possibility that AT
users will be able to interact with it as the author intended.

regards
stevef


[1] http://lists.w3.org/Archives/Public/public-html/2011Mar/0067.html
[2] http://dev.w3.org/html5/spec/Overview.html#wai-aria
[3] http://www.html5accessibility.com/tests/aria-changes.html

On 10 April 2011 18:14, Ian Hickson <ian@hixie.ch> wrote:

> On Sat, 9 Apr 2011, Steve Faulkner wrote:
> >
> > Hi ian,
> > you wrote on IRC:
> >
> >    1. <Hixie> oh wow, this is awesome
> >    2. # <http://krijnhoetmer.nl/irc-logs/whatwg/20110409#l-97> [01:09]
> >    <Hixie> the aria thing actually breaks h1-h6 in ATs
> >    3. # <http://krijnhoetmer.nl/irc-logs/whatwg/20110409#l-98> [01:10]
> >    <Hixie> (it removes their nesting depth)
> >    4. # <http://krijnhoetmer.nl/irc-logs/whatwg/20110409#l-100> [01:10]
> *
> >    Hixie cries a little inside
> >
> > As i know this is of great concern to I think you will be pleased to find
> > out that youhave misinterpreted the changes to headings:
> >
> > If you had looked at the spec changes i had provided and which Sam and I
> > pointed you [1] to you and Sam had agreed was representative of the
> decison
> > you would have seen that
> > Hx continues to have the same default role and allowed role of heading:
> > "heading role, with the aria-level property set to the element's outline
> > depth"
> >
> > I don't think that the other chairs would disagree?
>
> The changes you describe are quite clearly not at all an occurate
> portrayal of the decision, since there are changes listed there that are
> not listed in the change proposal at all. For example, your document has
> all manner of changes relating to tables, which are not even mentioned in
> the change proposal or the decision. Plus, regarding headings
> specifically, your table suggests that authors should be required to apply
> an aria-level="" property to every heading, which is just absurd.
>
> I confirmed with Maciej before making the change that the list in the spec
> is in fact what the decision was, and after going through the change
> proposal details and the decision himself, he agreed that bug 10066
> comment 33 accurately represented the change proposal and decision.
>
> Given that the decision has all manner of what I consider mistakes (e.g.
> it is inconsistent about whether menuitemradio and radio vs
> menuitemcheckbox and checkbox should apply at the same time, it gives
> different allowed roles for <area> and <a>, it has the quite ludicrous
> decision of allowing buttons to be exposed as links and radio buttons, and
> it even allows a heading to be made into a treeitem, not to mention the
> issue above regarding not allowing headings to be marked as headings), I
> intend to exactly follow the chairs' decision as written here, and not
> apply my own judgement.
>
> If we're allowed to start questioning the decision, there are certainly a
> lot of things I'm eager to have changed as well.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html