391713 - (simplearia) Simplify ARIA roles & attributes in text/html -- deal with the namespace dependency

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

HTML 5 is the way forward -- most likely XHTML usage will remain small.

Therefore namespaces are a signicant barrier for ARIA adoption. It's too hard to use them in text/html.

So at least in text/HTML we should allow ARIA roles and attributes without looking at what the namespace is. That way, whatever solution the HTML 5 community comes up with for ARIA attribute usage, the Firefox 3 implementation will be ready.

Comment 1

[Aaron Leventhal]

It would still be strict in application/xml+xhtml

Comment 2

[Aaron Leventhal]

One problem, I suppose we should allow the author to do both:
setAttribute("aaa:required", "true") or
setAttributeNS("http://blahlbalh", "aaa:required", "true") or
setAttribute("state:required", "true") etc.

There could be multiple attributes on the same node for required. But, I think we could deal with that.

And then there are HTML attributes with the same name as the ARIA attribute. On might have disabled="disabled" instead of disabled="true" in HTML. In fact, in HTML disabled="false" means it's disabled -- any value on the disabled attribute.

Comment 3

[Aaron Leventhal]

Another possibility is to hardcode the meaning of "aaa:" into the HTML parser.

Comment 4

[Aaron Leventhal]

Possibilities:

1) Relax namespace checking in text/html, dont' require a namespace. Allow ARIA attributes to use directly in markup.
Cons: Possible conflicts with attributes. For example, disabled="false" on an form control in HTML means it is actually disabled, because any value turns it on.

2) Recognize actual attribute name prefix "aaa:foo" as ARIA attribute names in Mozilla's DOM to a11y API mapping code.
Pros: authors can just use setAttribute() and it will also set an attribute with the same name in IE and other browsers. The script and DOM will look the same.
Consistently having "aaa:" as the prefix might simplify authoring and testing.
Cons: HTML community may not like requiring it to have "aaa:" prefix. They may want some other kind of prefix.

3) Hardcode meaning of "aaa:" into parser
Cons: Requires change to parser
Script author still has to use setAttributeNS() in browsers with namespaces vs. setAttribute() in IE. Script and DOM now look different in IE vs. Firefox.
Not sure what the benefit is over #2

Comment 5

[Aaron Leventhal]

And for roles, I suggest that wairoles no longer require a namespace prefix at all, and are just recognized. If there is no prefix for a role name it would just default to looking in xhtml (already does) and wairoles.

Comment 6

[Aaron Leventhal]

Ah, I remember the pro of #3 over #2. The author can use setAttribute() but the mozilla/accessible code doesn't need to check for both "aaa:attributename" and the actual namespaced attribute.

Comment 7

[Henri Sivonen (:hsivonen) (on leave)]

To me, #1 seems preferable except for name conflicts. However, to the extent there are name conflicts, is it even necessary (in HTML) to use ARIA attributes instead of the HTML5 disabled and required boolean attributes?

#2 scares me, because using the colon in the local name of the attribute would be namespace-ill-formed on the XHTML side and, therefore, would make the HTML and XHTML DOMs diverge for good, which would make the migration barrier between the two even higher.

Doing something like #3 keeps popping up in the context of HTML5. I see some kind of inevitability to it unless it is decided specifically to resist the introduction of namespaces to HTML5. However, due to legacy issues with IE and existing content, this is going to be very difficult to spec, which is why putting something like it in Gecko in the Firefox 3 time frame does not seem like a good idea to me.

So in summary, I suggest exploring doing #1 in a way that doesn't use ARIA true/false attributes but HTML-style boolean attributes where the presence--not the value matters.

CCing Hixie.

Comment 8

[Aaron Leventhal]

> is it even necessary (in HTML) to use ARIA attributes
> instead of the HTML5 disabled and required boolean attributes?
Some of them are slightly different. For example, checked="false" means something is checked in HTML. In ARIA it means that it is not checked, but potentially is checkable. If the checked attribute is missing in ARIA this indicates that the element is not checkable. For example this is useful on tree/menu/list items that have a checkbox.

Comment 9

[Henri Sivonen (:hsivonen) (on leave)]

Looking at the list of properties, it does seem a bit heavy to put them into HTML wholesale. Hixie?

Comment 10

[Hixie (not reading bugmail)]

It's not clear to me that we want the ARIA roles and attributes at all on the long term. My recommendation would be to use non-namespaces attributes throughout, and to give them some sort of vendor-prefix, as in:

   aria-required="..."
   aria-state="..."

...and similar. (These aren't namespace prefixes, they're just textual prefixes.) In particular, do not use unprefixed attributes in HTML5, as that will result in conflicts with whatever attributes HTML5 does invent (like "required").

Comment 11

[Aaron Leventhal]

That works for me. 

With a "aria-" as the prefix an element can be styled in IE 7 using an attribute selector. Although you can have a colon in an attribute name in IE with text/html, I can't find a way to style that with an attribute selector.

So :
[aria-hidden] { display: none }        -- works in IE
[aria:hidden] { display: none }        -- doesn't work in IE

Comment 12

[Aaron Leventhal]

I spun off the simpler role prefix issue (not requiring a QName for WAI role usage when in text/html) to bug 395909.

Comment 13

[alexander :surkov (:asurkov)]

Is it worth to keep this bug open in the light of bug 398910? Is this bug still actual?

Comment 14

[Aaron Leventhal]

Dealt with via the dependencies.