337128 - Support universal DHTML accessibility properties

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

The W3C WAI PFWG is looking to make some accessibility properties universal -- the can influence accessibility on any element. This is a reversal of our previous policy, which was to only check for them if there was also a role attribute. These properties don't influence anything other than how we expose an element to accessibility APIs, so we only deal with them in mozilla/accessible.
"http://www.w3.org/2005/07/aaa" "disabled"
"http://www.w3.org/2005/07/aaa" "required"
"http://www.w3.org/2005/07/aaa" "invalid"

I don't yet know how of these many universal properties we'll end up with.

The reality is that these attributes rarely occur. I'm thinking over what the most sensible code to check for their presence would be, given that they're rare and we could end up with 3-10 of them.

1) I could first check the element to see if there are any namespaced attributes at all -- if so I could go check for each namespace attribute pair via nsIContent::GetAttr. It would be great if there was a quick check for that.
2) I could first check the element to see if there are any namespaced attributes in this namespace -- if so I could go check for each namespace attribute pair via nsIContent::GetAttr
3) I could continue just using nsIContent::GetAttr() for each attribute on the element

What is the most sensible code to check for these attributes would be, given performance tradeoffs. I'm not sure if it's worth walking the attributes one at a time or not.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is any of these attributes required in order for the other to have meaning? I.e. can you check for the existence of one of them and bail if it's not there?

If not, I think it's pretty much a toss-up between stepping through all attributes using GetAttrNameAt or calling HasAttr three times. Neither is super perfomant though, so it might be an idea to give feedback on that to the WAI WG. Though it might not matter that much since perfomance might be good enough anyway.

Comment 2

[Aaron Leventhal]

(In reply to comment #1)
> Is any of these attributes required in order for the other to have meaning?
> I.e. can you check for the existence of one of them and bail if it's not there?

It used to be that none of the property attributes were relevant unless there is a role attribute. The WAI wants to change that and have a few 'universal' attributes that are not dependent on any other attribute or element type. I don't know how many we'd end up with.

Comment 3

[Aaron Leventhal]

Would it be useful anywhere else in the code if we had a
PRBool nsIContent::HasNamespacedAttr() method?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

As of today I don't see anyone else needing it. If CSS selectors were to support the syntax [ns|*=bar] then that could use it, but that is currently not the case.

Comment 5

[Aaron Leventhal]

Attachment: For perf testing, work in progress

Comment 6

[Aaron Leventhal]

Attachment: Patch for trunk -- not for review (waiting for final word on what properties will be universal)

Comment 7

[Aaron Leventhal]

Attachment: Patch for branch -- not for review (waiting for final word on what properties will be universal)

Comment 8

[Aaron Leventhal]

BTW, these 2 patches created absolutely zero performance impact.

Comment 9

[Aaron Leventhal]

I fixed this with bug 342979.