Re: changes to headings in ARIA in HTML5

a clarification,
I was incorrect when I said ANY element in HTML5 can be turned into a
meu item by adding an accesskey attribute and placing in a menu, it's
only elements categorised as flow content [1]:

a
abbr
address
area (if it is a descendant of a map element)
article
aside
audio
b
bdi
bdo
blockquote
br
button
canvas
cite
code
command
datalist
del
details
dfn
div
dl
em
embed
fieldset
figure
footer
form
h1
h2
h3
h4
h5
h6
header
hgroup
hr
i
iframe
img
input
ins
kbd
keygen
label
map
mark
math
menu
meter
nav
noscript
object
ol
output
p
pre
progress
q
ruby
s
samp
script
section
select
small
span
strong
style (if the scoped attribute is present)
sub
sup
svg
table
textarea
time
ul
var
video
wbr

[1] http://dev.w3.org/html5/spec/Overview.html#flow-content

regards
Stevef


On 11 April 2011 11:00, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>
> 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, whose Type facet is "command", and that is a descendant of a menu element whose type attribute in the list 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
>



--
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

Received on Monday, 11 April 2011 10:24:12 UTC