<davidb> passcode?

<Stevef> aapi

<davidb> thanks... trying for 3rd time

<Stevef> html5 / aria element mapping table http://www.paciellogroup.com/blog/misc/ARIA/html5-elements1.html

<scribe> scribe: Andi

<scribe> meeting: AAPI

<scribe> chair: Cynthia

SF: maps HTML elements to related aria roles
... if something is in the DOM, it can't be overridden

CS: everything in the DOM is overridable
... agree that elements that have strong semantics shouldn't be overridden

DB: are we talking about telling authors they shouldn't override them or that we shouldn't allow it

<cyns> url?

html5 / aria element mapping table http://www.paciellogroup.com/blog/misc/ARIA/html5-elements1.html

DB: ARIA is so that authors can tell ATs what's going on
... worry that we're not all on the same page about what ARIA is for

SF: agree - but we need to document the reasons

CS; consistency - like idea of attributes having default values, seems like a good education tool, seems clean as an implementation

DB: code would not be that clean

CS: like it best for interactive element - HTML menu tag, query role, it would be menu

DB: think that would happen without adding ARIA to the DOM
... worry is that there are people who think we are adding ARIA to the DOM automatically
... should map markup based on markup semantics, where author adds ARIA markup, we take that

CS: didn't mean to say add ARIA to the DOM, some attributes have default values which can be changed by ARIA
... worry about "checked" and "aria-checked"

DB: if markup gives you what you want, use markup

CS: worry about "input type=checkbox" and "command type=checkbox" too
... command is like a menu but can have input controls
... several places in HTML 5 where there are multiple ways of doing things, not clear how an author knows which to use
... if you're overriding a heading to be a banner, maybe should generate a warning
... but not sure it shouldn't be allowed and not sure it should even be a validation error

SF; it's a matter of working out when it should be a warning and when it shouldn't be

SF: the role doesn't do anything except explain to the AT "what" something is. It's the behavior that really makes it what it is.

CS: need to be pretty targeted about it.
... ARIA role on iframe or object doesn't make much sense
... canvas does because it can be an image

SF: iframe could be a document or an alert
... might want AT to go into application mode to interact with a video

DB: who gains if we limit the ARIA roles you can put on an element

SF: end user will gain if the developer is not coding it correctly

DB: potential to gain something if people are doing something they shouldn't be at a cost of making it more complicated
... simplify the browser implementation by just saying use ARIA if it's there

CS: okay with that but may not be the right answer for validators

SF: best way to tackle is to look at what's currently in the spec and chip it away
... only arguing about the stuff they see as problematic, like the "a" element
... what are the arguments for overriding something

CS: make a column in the table for what is being proposed as something that can't be overridden
... add a column for strong/weak?

SF: better to start with the spec table

<davidb> is http://etherpad.com/ accessible?

SF: find the ones we disagree with, start to get some arguments together as to why we disagree
... crosses some other work so should get others involved as appropriate

CS: HTML 5 accessibility task force hasn't started yet. Looking for facilitators now.

SF: will grab tables from HTML 5 spec, put into Excel document, then we can divide up

Looking at tables in 3.2.6 of html5 / aria element mapping table http://www.paciellogroup.com/blog/misc/ARIA/html5-elements1.html

<a> element - does have a native mapping but disagree that semantics can't be overridden

CS: thinking multiple columns
... native semantics, override yes/no, mappings for each API (start with MSAA)

SF: landmark roles don't really make sense

CS: override column could list the types that can override it

AS: rationale for why we think things can be overridden?

SF: yes

CS: add comments column
... sounds like everything can be overridden by widget because can turn any text element into something interactive

SF: can't think of an example of where "radiogroup" would be appropriate for <button>

CS: might make sense to override <button> with more specific kinds of buttons or commands

SF: been looking at canvas lately - stretch map over canvas and add focusable elements using ARIA

<area> - like <a> - all widgets should be allowed

SF: why can't the HTML element name be passed through as a role

CS: MSAA is a fixed set of names
... have a text field in UIA - map ARIA role to control type (like MSAA role), put full string into text field

DB: in FF, put it in the object attributes

CS: not mapping any HTML elements to text field in UIA

SF: Aaron said that things like Outlook pass through text strings in MSAA
... FF does this sometimes even when there is an MSAA role
... status of IE bug on aria-describedby support?
... aria-describedby doesn't map, aria-labelledby does map

<h1> element - widget

SF: outline algorithm changes heading level?

CS: sounds way too complicated
... agree default mapping to heading with aria-level is appropriate
... thinks there is an MSAA heading role

DB: IA2 has a heading role

CS: not used much because documents aren't done with MSAA

SF: for headings - widgets, subset of document structure?

CS: not sure it makes sense to put ARIA document roles on a heading to change its role

<scribe> No progress on bugs

Andi working on integrating error handling FAQs back into the main document

Next week, discuss 3.4 and 3.5

<davidb> one thing... I think "Strong native semantics and implied ARIA semantics" should be "Strong native semantics and implied AT semantics" since we don't map native markup to aria

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Andi
Inferring ScribeNick: Andi

WARNING: No "Topic:" lines found.

Default Present: Andi_Snow_Weaver, Stevef, David_Bolter, Cynthia_Shelly
Present: Andi_Snow_Weaver Stevef David_Bolter Cynthia_Shelly
Got date from IRC log name: 06 Oct 2009
Guessing minutes URL: http://www.w3.org/2009/10/06-aapi-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report