# [02:21] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [02:42] <DougJ> I have not been able to follow the html-wg for some time. I have been reviewing the Maciej 'Proposal for Keyboard Shortcuts' and the Aaron 'ARIA in HTML threads.' Please comment on my take - <command> shortcuts would be used on 'plain' HTML pages, ie. the author does not use Javascript and ARIA would require the use of Javascript. Does ARIA provide any more functionality?
# [02:43] <mjs> ARIA is not a mechanism for keyboard shortcuts
# [02:46] <aaronlev> i guess the 2 are complimentary, for good web 2.0 accesssibility you need both key nav and aria
# [02:46] <mjs> I'm not sure what you mean by "implement key nav with script"
# [02:47] <mjs> my proposal is for keyboard shortcuts for commands (like things you would find in the menu bar for a native app), not for keyboard navigation of controls (like with tab / shift-tab)
# [02:48] <mjs> I don't see how ARIA is at all related to this
# [02:51] <DougJ> Thanks for the clarification - I was tending toward that.
# [02:51] <aaronlev> yes right now if you want keyboard shortcuts you have to hack it with an onkeydown listener on <body> or something
# [02:51] <aaronlev> onkeypress doesn't work the same in IE as others, so onkeydown works better i've found
# [02:52] <aaronlev> IE doesn't fire onkeypress for everything you'd think it should
# [02:52] <mjs> key events are an area where interoperability is lacking
# [02:52] <mjs> and sadly the relevant DOM specs do not cover them at all
# [02:53] <mjs> browsers also differ on whether you are allowed to see the key events for key combinations that are built-in browser shortcuts, and whether you can prevent the default action on them
# [02:54] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
# [02:54] <aaronlev> i had to do a ton of work on all aspects of keyboard stuff in mozilla
# [03:00] <DougJ> Observing the HTML5 communications at least showed me that my troubles in understanding some HTML4 weren't just me. And I appreciate more the UA developer's. And I also wonder how some of this 'basic' stuff was left alone in specifications? Oh, well, water over the ...
# [07:15] <karl> this is a name identifying a person sending messages to the list. But that doesn't say what this person is doing related to this technology for hobbies, pro activities, etc. outside of the html wg life
# [07:49] <Hixie> he's been a contributor for a long time, though, and many of his ideas have strongly influenced wf2's development
# [07:51] <karl> yes it is why I would like to know what he is doing. To have strong opinions like this, he must be using the technology in a product or something or developing himself.
# [07:51] <karl> This could be interesting to know what products, if any
# [07:51] <Hixie> i had strong opinions long before i had any reason to :-)
# [07:52] <karl> The name could be a mask to hide a company.
# [07:53] <karl> We all have strong opinions. And we often make fool of ourselves in public. Internet Information space is 2d (very binary), when human information space is indy (bad play of words.)
# [08:19] * Quits: hober (ted@68.107.112.172) (Quit: ERC Version 5.3 (devel) (IRC client for Emacs))
# [13:19] <anne> it's not very nice from MS to come with this I think as they haven't really contributed to any discussion and haven't acknowledged all the steps we made in the direction of their implementation
# [13:19] <anne> mostly if there was a difference the IE way was picked, even when it was quite insane
# [13:22] <mjs> it seems pretty late to object but I guess they haven't been following closely
# [13:22] <mjs> to object in such a fundamental way I mean
# [13:23] <mjs> but I also think "please make the spec toothless" is not a valid request in any case
# [13:24] <hsivonen> it would certainly be nice if they said what's incompatible and how to change the spec to make it compatible
# [13:25] <mjs> they said they don't have the resources to do extensive testing, and that they are unwilling to make any changes at all to their existing code
# [13:26] <mjs> both of those seem like they would conflict with the idea of documenting the issues in detail
# [13:26] <anne> the vision document is quite funny
# [13:26] <mjs> I'm not sure they have real compatibility issues in mind, they just say any change might be a compat issue
# [13:26] <anne> it talks about HTML parsers being expensive for mobile devices
# [13:27] <anne> where a parser is one of the least significant things in a browser in terms of being expensive
# [15:24] <zcorpan_> aaronlev: only one thing: the proposal says to look at the first token (regardless of what it is), they want to look at the first aria token, if any
# [15:25] <zcorpan_> aaronlev: consider role="blah checkbox" vs role="checkbox blah"
# [15:26] <zcorpan_> aaronlev: in firefox, do you pick up "checkbox" in the former?
# [15:26] <aaronlev> no, we just look at the first
# [15:26] <aaronlev> but also, we expose an object attribute called xml-roles
# [15:27] <aaronlev> which is just the role attribute exactly reproduced char for char
# [15:27] <aaronlev> i realize that doesn't help much though
# [15:27] <aaronlev> i'm sure we could do better with multiple roles, but no one is doing that yet
# [15:28] <aaronlev> in fact no one is really using roles as landmarks at all, even the obvious ones like main and navigation
# [15:29] <aaronlev> i guess, we have worse issues that i see as more important -- like harmonizing tree grid across platforms, handling the owns property better, caching relations (which i guess opera already does), and a few other things
# [15:31] <aaronlev> zcorpan_: but if you decide it's worth putting into the proposal, i should be able to do it for ff3
# [15:33] <zcorpan_> aaronlev: on the one hand i'd like to address al's concern, but on the other hand it's a minor issue and i'd rather try to spec down the remaining big issues first
# [15:34] <zcorpan_> it just requires authors who wish to use multiple roles to put the aria role first
# [15:44] <zcorpan_> aaronlev: i changed the draft to expose the entire value in "xml-roles" (it said to only expose the role identifier it found for the mapping purposes)
# [15:48] <aaronlev> ah, so are you going to start putting a11y API details in there?
# [15:48] <aaronlev> i think it's a good idea to do that, but, not all a11y apis are the same
# [15:51] <aaronlev> so IBM worked with the community to build IAccessible2, which are API extensions to MSAA and matches closely with ATK/AT-SPI on Linux
# [15:51] <aaronlev> it's what we're using in FIrefox now
# [15:51] <aaronlev> because it can build on msaa support and yet is very similar to ATK, you can leverage a lot of existing code and get cross platform a11y
# [15:52] <aaronlev> the AT vendors had a lot less work to implement support for it, because they get to build on top of exisiting support for MSAA
# [15:52] <hsivonen> aaronlev: is Universal Access a good match?
# [15:53] <zcorpan_> aaronlev: the proposal references that :)
# [15:53] <aaronlev> hsivonen: universal access is cool because it just name value pairs. It's loosely spec'd which honestly is an advantage in this space, because you don't have to rev a whole lot of binary software in lock step to get new features in
# [15:53] <aaronlev> you can just expose some new a11y property
# [15:54] <aaronlev> But with binary APIs, adding new features is a total nightmare
# [15:54] <aaronlev> hsivonen: and the values in the name value pairs don't have to be strings, it can be a hash table for example
# [15:54] <aaronlev> so you can send any event data you want, for example, it's great
# [15:55] <aaronlev> the big disadvantage is that there is really only one (closed) screen reader supporting it, which is owned by the platform vendors
# [15:55] <aaronlev> so it is harder to influence them if you need new features, like accessible live regions or drag and drop, or whatever
# [15:55] <aaronlev> but, to answer your question, the name/value pairs Apple is using most likely fit well enough, but we only have stub support for UA in Mozilla so I can't say what the major integration issues will be yet
# [15:55] <hsivonen> aaronlev: OK, so one needs to know the magic keys supported by VoiceOver instead of merely writing to a particular set of function calls
# [15:56] <aaronlev> hsivonen: right, and you can find out by looking at other apps
# [15:56] <aaronlev> that apple has written, or looking at their docs
# [15:56] <aaronlev> but docs are always wrong or out of date for anything like this
# [15:57] <aaronlev> my big concern with spending a lot of resources on UA support in Mozilla is, how will we get Apple to change Voice Over when we need it, when obviously Safari is more important to them. I see a conflict of interest, but they aren't interested in open sourcing it
# [15:57] <aaronlev> So we might let Opera take the lead on that one :)
# [16:00] <aaronlev> but to be honest, if i had resources i'd consider putting them into ARIA support in WebKit first, because then we can influence Voice Over first
# [16:00] <aaronlev> once everything works well there, we'll know exactly what support in Mozilla should look like
# [16:00] <aaronlev> since my goal is a11y for the whole web
# [16:21] <hsivonen> zcorpan_: the reasons for lacking text field and file upload are three-fold:
# [16:22] <hsivonen> 1) lack of UI design that works nicely without JS, with AT and doesn't bloat the default view
# [16:23] <hsivonen> 2) handling file uploads doesn't come for free with servlets. instead I have to do so disruptive integration of a third-party library
# [16:23] <hsivonen> 3) Should I force the user to pick the parser manually, when Content-Type is unavailable (text field) or unreliable (upload)?
# [16:32] <Lachy> one day, I'll clean up those tools of mine to be more useful for testing hsivonen's validator.
# [16:32] <Lachy> zcorpan_, let me know if there are any changes I could make to it to improve it for you
# [16:34] <zcorpan_> Lachy: i've used your upload tool as input for validator.nu (not html5.validator.nu) when i wanted to change preset or something
# [16:35] <Lachy> maybe I could add a function to do that in one step for you, so it generates the page and redirects you to the validator with it immediately
# [17:16] <aaronlev> zcorpan_: don't forget the xhtml role module roles have no prefix
# [17:16] <aaronlev> so that rule wouldn't work for role="navigation menu"
# [17:20] <zcorpan_> yeah, true. perhaps i instead need a table of all aria roles
# [17:21] <aaronlev> zcorpan_: i have an array of wai-aria roles in alphabetical order. i think the most performant rule to implement might actually be: 1) get the role attribute, 2) for each aria role in alphabetical order, check to see if it is in the the role attribute
# [17:22] <aaronlev> that way you only have to iterate once