See also: IRC log
<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[End of scribe.perl diagnostic output]