ARIA States and Properties Meeting

I will be hosting a joint meeting Wednesday, October 31 at 9:00AM EST,
13:00 GMT to build W3C consenus on supporting ARIA more easily and
consistently between HTML, XHTML and SVG. This is an invite for interested
parties. The meeting duration will be 1 hour. Mike Cooper will be following
up with bridge call-in information and the meeting witll be openly minuted.

Background on ARIA markup inclusion discussion:

1. ARIA property usage depends on the language type -- it is not consistent
A. XML uses namespaced attributes: ARIA properties can be used by
namespacing them, e.g. aria:activedescendant="[id]" per the ARIA
specification today.
B. The HTML working group proposes using hyphenated attributes: in the case
of text/html, namespaces are not available, e.g.
aria-activedescendant="[id]"

2. Colon is not an option for text/html
We cannot use the colon instead of a hyphen, because a colon in attribute
names causes problems in IE. For example, you cannot use CSS attribute
selectors in IE when using a colon in the attribute name. Use of CSS
attribute selectors is a very important tool for authors developing dynamic
widgets. There are other problems with the colon in IE, but the CSS
attribute selector problem alone is enough to make it non-viable. We are
weakening the tools in the author's toolbox.

3. XHTML 1.x DOM processing must be the same as text/html
Because browser vendors require equivalence in how they process elements in
the namespace  http://www.w3.org/1999/xhtml it is proposed by the browser
vendors that the hyphenated attributes are also available in XHTML 1.x. It
is not considered sensible to alter the processing of the DOM depending on
the mime type.

Therefore, namespaced properties with colon are also not viable as the only
solution for XHTML 1.x,.

4. SVG Would also like to use ARIA

There are problems with using hyphenated attributes in SVG.

5. Requirements
A. Allow content to be developed that is functional in older and newer
browsers
B. Allow ARIA properties to be declared in text/html
C. Provide consistent usage of ARIA properties for elements  in the
http://www.w3.org/1999/xhtml namespace, no matter what the mime type
D. Do not cause unnecessary burden on browser manufacturers or authors
E. ARIA can be used in SVG

It would benefit ARIA adoption, and thus people with disabilities, if the
community can come to an agreement on consistent markup for usage of ARIA
properties.

6. Currently proposed solutions for ARIA states and properties (not role)
A. Use hyphenated property everywhere .
Pros: consistent
Cons: The issue that has been raised on this is that SVG already has
properties with hyphens in it. However, proponents of hyphen state that SVG
has no properties starting with "aria-" so it is not a real problem, and
that another character (see #2 below) would confuse authors to have some
hyphenated properties and some with another separating character (such as
underscore).

B. Use of a different separating character such as _:  (it's worth
mentioning that there was a discussion around this, but there was not
enough support for it).
Pros: allows ARIA consistency across markup. Could allow validation schemas
to not include ARIA markup
Cons: inconsistent separating character -- authors may not remember whether
to use - or _. Considered non-asthetic by many. Given the strength of
opinions expressed, it seems that no consensus will emerge to follow this
approach. A new general namespacing mechanism for predefined prefixes
cannot solve the problem, as it would cause differences older browsers and
newer browsers.

C. If no consensus is reached, the current split processing which depends
on element type may need to continue. Currently Firefox will support both
namespaced and hyphenated properties.
Pros: ARIA works in HTML, but namespaced properties which are
schema-friendly are still supported. Note that so far everyone agrees that
schema is a tool and should not drive the technology too much
Cons: inconsistent; indicates that community split on namespace philosophy
will continue to cause problems for authors and end users

D. For long term consideration: Should the W3C consider create a collection
of cross-cutting attributes which may be used across renderable markup
languages without namespaces. e.g. (Role, ARIA, RDF/A, etc.)

Thank you,
Rich


Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer