ARIA/HTML5 breakout session, Santa Clara, California -- 05 Nov 2009

<wendy> aloha gregory!!

<oedipus> is there a telephonnic bridge for this slot?

<oedipus> FYI: html wg schedule for day 1: http://spreadsheets.google.com/pub?key=tAbypWTudUfZZQMT2iSR6xg&output=html

<oedipus> being updated in real-time

<Laura> Hi

<silvia1> what room is this meeting in?

<silvia1> (actual location in hotel - there are three of us wondering around)

<myakura> silvia1: 1243 in the north tower

I'll try to keep notes. Feel free to correct

setting up projection

Intros

Cynthia Shelly, Microsoft

Steve Faulkner

Wendy Chisholm

Glenn Bookout

Matt, adobe

Sylvia Pfieffer

Msataka Yakura

Eliot Graff

John Foliot

Eric Carlson

Michael(tm) Smith

Janina Sajka

things to cover

working on setting up a phone link

ARIA and HTML, semantics and overrides

Things to cover: ARIA & HTML both have ways to define semantics of elements

scribe: oely related but created separately

HTML is not very well suited for marking up UIs

"marking"

<Stevef> link to google doc of ARIA mapping http://spreadsheets.google.com/ccc?key=0AlVP5_A996c5dG9RSE9GMy1JaVlBQ2dIWDliczJHckE&hl=en_GB work in progress

turned difs and spans but often doesn't work for users with assistive tech

ARIA fills some gaps

HTML5 fills some of those gaps, but in different ways

the goal here is to understand overlaps bet HTML and ARIA, how they relate

and specifically for HTML, when you apply ARIA, how do the changes take effect

spreadsheet shows overlaps and HTML implementations

this is taken from Ian's work, but not identical to Henri's work

1st two columns are what's in HTML5

<cyns> http://www.w3.org/WAI/PF/aria/rdf_model.png

<Stevef> link to google doc of ARIA mapping http://spreadsheets.google.com/ccc?key=0AlVP5_A996c5dG9RSE9GMy1JaVlBQ2dIWDliczJHckE&hl=en_GB work in progress

this second link is the model for ARIA roles and how they relate

input types are similar to HTML mapping

HTML interractive section: defines a command

all of the elements that "do stuff"

<cyns> http://dev.w3.org/html5/spec/Overview.html#interactive-elements

<myakura> command def in html5: http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#commands

CS: ARIA spec says ARIA always wins & HTML says don't put a bunch of roles
... HTML maintains backward compatibility to non-ARIA browsers

SF: if you put a role of button on a link, it doesn't change anything but the AT knows it's a button
... a hint to user to tell how to interact, doesn't impose any new behaviors

CS: n event handler does change the behavior
... ARIA patches that mismatch
... a whole lot of DHTML is not accessible and ARIA's a fix
... we want to avoid errors that someone repurposes an element

SF: if people get a warning or type mismatch, they may take the ARIA off to get rid of the error. e don't want that.

<Hixie> the spec says that validators have to complain about the element, not the aria role, which should take care of that

Other topics other than what's on the spreadsheet?

doesn't seem to be

look at the spreadsheet: first column is the feature, second is the default role, third is accepted overrides

CS: widget types and structure typs. a big dsemantic diff
... in HTML content and UI are mixed

fire alarm is going off

<Stevef> ARIA roles added to the a element should be conforming in HTML5 http://www.w3.org/Bugs/Public/show_bug.cgi?id=8000

SF: link is to initial bug around the issue

Look at <a>. It defines a command; link is in the input roles.

it's overriden in the wild

button is like that

all of the things in HTML that define a command (bottom of sheet)

In the spreadsheet: should it be overriden? Where? Why?

CS: we are trying to agree that there are groups of overrides: structures, widgets, (and commands as a subset of widget) is the proposal
... HTML has navigational kinds of rols, too.
... one other thing that the TF will do is to look at the sets and try to get them to match.
... looking for input here if these groupings make sense;

WC: are there objections?

CS: HTML elelments will throw an error if you put an ARIA role on them

<Hixie> it's not clear from the minutes what the goal of these groupings would be

CS: Goal of groupings would allow more overrides than are in the spec, to support things that are currently done in the wild: like repurposing lists as menus; links as buttons
... tables as tab panels, etc.
... and to have fewer validation warnings for ARIA implementation.
... don't want a page to be less valid if you add ARIA.
... if the warnings cause developers to remove ARIA, it would be a bad thing.
... Seeing nods around the table

Looking for consensus around this approach

<Hixie> so the categories would be things that are conforming and correct, things that are wrong and not conforming, and what?

CS: Grouping is about UI elements versus document elements
... Example: if you take an HTML element and add compatible ARIA (in the same category) then that would be conformaing and correct
... if you add ARIA that's not in the same category, the DOM would still do it, but there would be a conformance error (but the browser wouldn't care)
... if you took a link and made it a menu item, that would be OK, but if you made it a contentinfo, that would not be OK
... let's look at the spreadsheet and examine specific cases
... to see if they make sense

<a> is a link and is a command. Command elements (in override column)

<address> Steve thinks contentinfo is incorrect

contentinfo is a langmodel role

it can contain information, but you should only have one contentinfo role in a single document

if the address has a default role of conteninfo it can cause duplication

CS: here's a place where ARIA shoul add a role

<MikeSmith> <prolix> contentinfo is broader than <addres>

<MikeSmith> <prolix> there isn't a 1-to-1 mapping between <address> in HTML5 and contentinfo in ARIA

<prolix> contentinfo is broader than <addres>

<prolix> there isn't a 1-to-1 mapping between <address> in HTML5 and contentinfo in ARIA

SF: the danger is that there's --in theory--instances of repurposing of doc element into widget role is not conformant in HTML, but you can't check that conformance
... you can change the way the user interacts, and it's OK, but when you stick an ARIA role on it, it CAN be checked. ARIA flags document conformance issues

CS: Broader issue of late-bound attributes, modified via script
... what can be done about that--if anything?
... having things found in the validator seems incorrect and may cause them to take the ARIA off.

<prolix> list of ARIA roles in http://www.w3.org/1999/xhtml/vocab/

<EC> it'll be difficult. the event handler will do different thingss, depending on use

<prolix> target should be trate by the UA as a suggestion -- a strong suggestion, but a suggestion by default, nevertheless

CS: maybe checking if a handler has a role?

SF: what point does scripted action cross into something that shouldn't be allowed

CS: is the real underlying issue that people are putting event handlers on things that are not supposed to? Does it make sense that an address have a click handler?

SF: It will change the conformance rules considerable for some elements

Does MS have any thoughts?

<prolix> but are you superfreaked out?

CS: Does it seem likely to be a deployment blocker?

MS: Hmmmm

CS: The new Accessability model from Microsoft has a concept of patterns
... woorth exploring for ARIA2: this is both a heading and clickable

MS: What exactly would change?

<prolix> structural elements, mainly

CS: a lot of the document items would not be allowed to be overridden

MS: This would be a warning?
... Then it wouldn't require a schema change

<SP> The validator should offer hints to make valid pages

<prolix> very good idea

MS: when Hixie made some things conforming but obsolete, we added warnings. If it's just changes the conformance checker, then it's doable
... Validator by design is made to conform to the spec

Looking for Henri's input

SF: The warning message should be agnostic: NOT "take off the ARIA"

Resolution?

Resolution: Event handlers on document elements with strong semantics would trigger validation warnings, as would ARIA roles on those same document elements. "Obsolete but conforming"

<MikeSmith> hsivonen, any thoughts on that?

work item: figure out what those elements are

<silvia> also, it would be a good idea to make suggestions to the author of the web page on how to improve their markup: did you mean to use a <button> element instead?

Discussion: <area>

<hsivonen> MikeSmith, warning on event handler attributes on strong-semantic elements categorically may likely clash with legitimate cowpaths

CS: What works for anchor should probably work for area

SF: RE: <area> what about an image that has a group of buttons?

CS: Links and buttons are similar
... We're trying to say that those cowpaths are bad practice

<MikeSmith> hsivonen, ↑

<prolix> cows are not only notoriously bad navigators, but are subject to the herd mentality...

CS: we could say if you have onClick, you have to have ARIA role, too

<hsivonen> whining about onclick without a role might work

<hsivonen> hard to say without trying it

<silvia> general agreement here in the room

<hsivonen> but e.g. <a> may have onclick and still behave like a link

MS: the validator is still experiemental, so we're free to play around with it.

<hsivonen> so in that case, it would be pointless to whine about lack of role

CS: the event handler is kind of a way to see if people are using semantically correct HTML

<MikeSmith> we have a test instance of the validator at qa-dev.w3.org that we can play around with more freely

<hsivonen> in general, my gut feeling is that warning about event handler attributes isn't going to go down well with authors

CS: a href="role:button" is probably OK, but a href role:paragraph is not

<hsivonen> the crucial question is: is there really a very strong correlation between event handler attributes and a legitimate need of explicit role

<prolix> http://www.w3.org/1999/xhtml/vocab/

<cyns> onclick should be allowable on elements that "define a command" but not on those that don't

<hsivonen> that is, will a warning "hey, you need a role here, too" be more often right or wrong

<cyns> That will be more often right, I think. By adding the event handler, you change the behavior, and implicitly changing the role

SF: We're saying "you're using an ARIA role and you shouldn't be"

<SP> As an author, this is educating. I wouldn't be bothered.

WC: UW has something like this
... How are organizations like Facebook going to feel about adding all this?

<hsivonen> cyns, you can also be retaining the semantics (e.g. link is still conceptually a link) but overriding the UA implementation of the semantic with JS

<hsivonen> lots of sites do that with links

<hsivonen> they don't change to being buttons

<cyns> true. I wouldn't warn for onlcick on a link, but I would warn for onclick on an <h2> or an <address> and other things that have strong document semnatics, but aren't usually clickable.

<cyns> but not on a div or span

SF: I have an issue with having all these warnings.
... poeple want to check to see if this piece of code will wrk properly, but the don't want to be told about bad/good practice
... We need to keep the warnings to a minimum

<prolix> amen, cyns

SF: we shouldn't be warning for the most part about roles

CS: What are the role of warnings?

Should we have best practive evaluators and thereby reduce the number of warnings we issue

MS: the philosophy behind the validator is informaing you about something you don't know already. It's not to let you know about stuff you're already doing and are aware of it.
... you don't want it to be annoying

SF: I'd want to know if I've used the right role and associated attributes
... have I spelled ARIAPressedState correcltly? I don't want to be told I can't do it.

CS: Do we want to warn of changing strong semantic elements or not?

<EC> Can we even do that?

<hsivonen> should <h2> have role=button if onclick collapses the section?

CS: That's really the wuestino. How loud to we want the validator?

<prolix> as noisy as the author wants stroke needs

<EC> To the extant that we're certain that adding and event handler changes the semantic behavior

Is this a policy question that bigger than this group?

What's the consensus about the noisiness of the validator?

Does this go back to diff validators focus on diff things?

MS: you want some level of interoperability among conformance checkers. They'll start using the one that gives them the least noise.

CS: There are some that are accessibility
... maybe these are something an accessibility evaluation tool would look for rather than an HTML validator
... we can put this stuff in the spec, we can be loosey goosey

<prolix> separate equals not equal

MS: Do we want to raise awareness around more naive authors? Then we don't want them to have to use a special tool. It should be in the spec

CS: Many authors are not aware that adding event handlers to these elements is a bad practice

SF: Is this a bad practice used?

MS: I don't know, but we could deploy this experimentally and tell them

<prolix> it just isn't done!

MS: If it's disallowed in 10 years, we can have another discussion about being more serious.

JS: There's a path toward deprecation that we can follow

CS: They should be using the right tag in the first place

JS: This tells them that this works but is not good
... maybe in HTML6 it'll change

<MikeSmith> hsivonen, talking about your h2 role=button question now

CS: Want to explore multiple roles in ARIA2, not in ARIA1

SF: could you having something like and ARIA-action attribute?

CS: MSA has a default action, too
... we hae a good question to bring to the larger group: Do we want changing of element handler and role semantics via attributes to be deprecated?

<prolix> thanks, all

<prolix> will the afternoon meeting e held in this IRC channel?

rssagent make minutes

rssagent, make minutes

<prolix> put a comma after it

<prolix> rrsagend, make minutes

<prolix> thanks, eliot_graff for scribing!

- DRAFT -

ARIA/HTML5 breakout session, Santa Clara, California

05 Nov 2009

Attendees

Contents

Intros

ARIA and HTML, semantics and overrides

Summary of Action Items

Scribe.perl diagnostic output