AAPI

 

 

<scribe> Scribe: Andi

Strong Native Semantics, mapping in HTML and ARIA

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