See also: IRC log
<scribe> Scribe: Andi
DB: have issues to raise
... will e-mail Cynthia
CS: looking at the spreadsheet
spreadsheet is a copy of the table from the HTML 5 specification
column C is from the HTML 5 spec, Column D is what we think should be allowed to override it
DB: can the ARIA implementation in the browser choose to respect the author's coding regardless of the table?
SF: yes
CS: thinks it's still under
discussion
... don't think we want different browsers doing different
things
DB: as long as we can decide within this group what the browsers will do, we're not tied to this table
CS: would like to make this
normative
... would be published in the HTML 5 spec
SF: this table is authoring conformance, not browser behavior
DB: we think it will be more accessible if we respect the ARIA coding
<Stevef> User agents are required to implement ARIA semantics on all HTML elements, as defined in the ARIA specifications. The implicit ARIA semantics defined below must be recognised by implementations. [ARIAIMPL]
CS: if query ARIA role on input type=button, you would get "button"
SF: references thread on
<a> element
... put in a bug on HTML 5 WG
... both Henri and Simon agree with ARIA overrides on <a>
element
CS: willing to go element by element is a good sign
SF: difficult subject - don't want to encourage people to write bad code - but if they do, want to encourage them to make it accessible
CS: ARIA was designed to fix bad code
SF: validator shouldn't be used
to discourage people including ARIA to make it accessible
... more important use of validation tool is to ensure that if
you're using ARIA, you're using the correct values in the
correct combination
... limited utility if only checking source code
... in most cases, will be adding ARIA stuff using
JavaScript
CS: prefer to have it in the markup because it's easier to understand the code
SF: if have it hardcoded and JavaScript is not available, it becomes meaningless
DB: HTML, CSS, and JavaScript are the way to do highly interactive stuff but it can't really be validated
CS: much harder to validate imperative, rather than declarative
line 41: input element with a type attribute in the Week state
SF: this is a date picker but
pick by week
... possible values of "type" are considered states
CS: adding column with markup in next rev
DB: column C is the default
role
... is browser ever adding ARIA to the DOM?
... currently, FF doesn't add ARIA to the DOM
CS: can see reasons for both approaches - don't think it's settled
DB: all browsers need to do it the same way
CS: can see implementation where it would be good to have all default roles populated in the DOM
DB: potential benefit for DOM-based AT
CS: if HTML spec describes as
default values for attributes, shouldn't be different from
other default attributes
... other default attributes are in the DOM
<cyns> Create Bug: Does HTML native semantic populate aria-role attribute with a default value in the DOM?
AS: nothing in the UAIG about how the UA populates the DOM
CS: think this is an HTML 5 issue
DB: but we probably want to make
a "suggestion"
... be interesting to know everyone's thinking on this
CS: ARIA has been used to fill in
holes in API implementations
... really have to know where the holes are in HTML to API
mapping to know when you need ARIA and when you don't
... back to line 41
... there's no ARIA role for a date picker is there?
SF: no
... added complexity - base control may be a button or text
field
CS: input type=week doesn't have a rendering?
SF: no
... the only current implementation is Opera
CS: has no role
... general issue with HTML 5 - no specified rendering - color
picker too
SF: some would say that's a
feature, not a bug - don't want to tell browser venders how to
do it
... implied that well-known controls have certain actions
associated with them
... ARIA issue is that a lot of them are not supported in
browsers
... a lot of the HTML 5 controls are not supported in browsers.
Need ARIA support to fill in the gaps.
<Stevef> http://code.google.com/p/html5-now/
CS: back to input type=week -
override with widget
... seems weird that there would be native semantics that can't
be addressed by ARIA
SF: color picker - like a dialog with things in it
CS: depends on implementation - client app - role would be "window", name would be title bar
<davidb> a colorpicker might map to MSAA ROLE_SYSTEM_BUTTONDROPDOWNGRID
CS: uncomfortable that there are things in native HTML which don't map to an API and you can't add ARIA.
DB: can't say the Web can only innovate in the space defined by ARIA
CS: concern with implicit roles in HTML that don't have matching ARIA roles
line 42: link element that represents a hyperlink
CS: how does this represent a hyperlink?
SF: think we should only be
looking at things within body (not head)
... link element can be in body in HTML 5
<Stevef> http://dev.w3.org/html5/spec/semantics.html#the-link-element
SF: relationship between HTML 5 last calls: whatwg vs. W3C version?
CS: when does link represent a hyperlink? can link appear in the body? is it exposed to uesrs?
line 43: menu element with a type attribute in the context menu state
CS: think there is an MSAA role
of menu
... should at least be an ARIA menu
... no role is inappropriate
SF: what about an abstract role?
CS: but we want something that will alert the user that there is an interactive element
SF: "no role" means no ARIA role
but there will be a mapping to the accessibility API in the
browser
... depends on what it is
bug - CS - how are context menus handled in MSAA?
CS: thinks "default role" would
be a better term
... mapping to ARIA roles which seems strange - thinks mapping
to APIs is clearer
... thinks they think map HTML to ARIA, then to API
... extra level of indirection that is not necessary
... seem to think that ARIA is an intermediate layer between
HTML and API
DB: agree that it "can" be but is not necessary - HTML can go straight to API
CS: better if specs reflect
that
... once we have defined equivalence between HTML and ARIA
elements, can define where HTML can go straight to APIs
SF: can discuss this document at TPAC next week if CS and DB have completed their bits
No meeting next week