Bug 391713 (simplearia)

Simplify ARIA roles & attributes in text/html -- deal with the namespace dependency

RESOLVED FIXED

Status

()

Core
Disability Access APIs
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Aaron Leventhal, Assigned: Aaron Leventhal)

Tracking

(Blocks: 1 bug, {access})

Trunk
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

10 years ago
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.
(Assignee)

Comment 1

10 years ago
It would still be strict in application/xml+xhtml
(Assignee)

Comment 2

10 years ago
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.
(Assignee)

Comment 3

10 years ago
Another possibility is to hardcode the meaning of "aaa:" into the HTML parser.
(Assignee)

Comment 4

10 years ago
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

Summary: Should we relax namespace requirements for ARIA roles and attributes? → Should we relax namespace requirements for ARIA roles and attributes, when used in text/html?
(Assignee)

Comment 5

10 years ago
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.
(Assignee)

Comment 6

10 years ago
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.
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.
(Assignee)

Comment 8

10 years ago
> 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.

Looking at the list of properties, it does seem a bit heavy to put them into HTML wholesale. Hixie?
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").
(Assignee)

Comment 11

10 years ago
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

(Assignee)

Updated

10 years ago
Summary: Should we relax namespace requirements for ARIA roles and attributes, when used in text/html? → Simplify ARIA roles & attributes in text/html -- deal with the namespace dependency
(Assignee)

Updated

10 years ago
Depends on: 395909
(Assignee)

Comment 12

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

Updated

10 years ago
Blocks: 396346
(Assignee)

Updated

10 years ago
Alias: simplearia
(Assignee)

Updated

10 years ago
Depends on: 396632
(Assignee)

Updated

10 years ago
Depends on: 397100
(Assignee)

Updated

10 years ago
Depends on: 397664
(Assignee)

Updated

10 years ago
Depends on: 343137
(Assignee)

Updated

10 years ago
Depends on: 398910

Comment 13

10 years ago
Is it worth to keep this bug open in the light of bug 398910? Is this bug still actual?
(Assignee)

Comment 14

10 years ago
Dealt with via the dependencies.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.