I'm not a real part of ARIA spec development but I work with assistive technology vendors and ARIA widgets authors on ARIA support in Firefox, I'm the one who implements ARIA in Firefox. I'm focused on practical aspects of ARIA usage and often I deal with problems not addressed by ARIA spec.
Here how it usually works. We and AT developers discuss a problem and then after agreement we implement just a reasonable solution that works for AT, users and us. We don't always go for a feedback from ARIA group and actually I think there's a number of reasons why. Personally I don't go probably because
On the another hand I don't follow the ARIA spec progress. I didn't see changelogs between spec versions. I wasn't really asked for feedback as ARIA implementator in Firefox. Because all of this many changes in the spec were introduced silently for me. I don't want to blame anyone (including myself) I just want to say that ARIA spec development was in parallel universe for me.
Yes, it couldn't be forever, one day Firefox implementation should meet the spec on the crossing and we should get a bump. This day have came. ARIA spec came into candidate recommendation and we were said Firefox don't pass tests. While I was running through failing tests one by one then I realized I have concerns for half of them. It wasn't a really big surprise but I disagreed what ARIA spec states in a number of cases. Here are few examples when I had concerns.
1) ARIA abstract roles must be not exposed via standard role mechanism (see the ARIA spec):
However if the browser follows this approach then we run into a problem because the browser must known about abstract roles to ignore them. Abstract roles are pure theoretical matter used to organize stuff in the spec, it's *not supposed* to be used on the web and it *won't* be used on the web but the browser *must* know about them if the browser relies on "expose any role" approach. In reality it slows down the browser for nobody's win. Ok, it's a browser problem. ARIA problem I think is the ARIA spec tries to standardize things that *aren't* supposed to be used on the web what is meaningless in general.
2) aria-checked="mixed" on radios should be mapped to "false" value (see the ARIA spec):
The problem is the candidate recommendation means nobody wants to change the spec at this point especially if it's implemented by some browsers already. It doesn't really make sense to address any issue listed above in the next spec since they don't make a difference on the web. It wouldn't be so bad to just follow the spec if we didn't have other discrepancies especially those that *make* a difference for the user.
The reality is either Firefox picks up that burden wordlessly or it gets an yoke of the browser incompatibility with the spec. No good options, huh?
Here how it usually works. We and AT developers discuss a problem and then after agreement we implement just a reasonable solution that works for AT, users and us. We don't always go for a feedback from ARIA group and actually I think there's a number of reasons why. Personally I don't go probably because
- I think somebody else could do that since it was a group decision after all.
- I don't always get feedback from ARIA group.
- ARIA group is perceived as a closed group (I always run into restricted areas the other participants are referred to).
- ARIA group structure feels complicated (there are two ARIA specs managed differently and when you have a single ARIA issue then sometimes you should go though different authorities to get a feedback).
On the another hand I don't follow the ARIA spec progress. I didn't see changelogs between spec versions. I wasn't really asked for feedback as ARIA implementator in Firefox. Because all of this many changes in the spec were introduced silently for me. I don't want to blame anyone (including myself) I just want to say that ARIA spec development was in parallel universe for me.
Yes, it couldn't be forever, one day Firefox implementation should meet the spec on the crossing and we should get a bump. This day have came. ARIA spec came into candidate recommendation and we were said Firefox don't pass tests. While I was running through failing tests one by one then I realized I have concerns for half of them. It wasn't a really big surprise but I disagreed what ARIA spec states in a number of cases. Here are few examples when I had concerns.
1) ARIA abstract roles must be not exposed via standard role mechanism (see the ARIA spec):
User agents MUST NOT map roles defined in the WAI-ARIA specification as "abstract" via the standard role mechanism of the accessibility API.It seems very reasonable since there's *no* any single reason why the AT would need it. But the statement might be colored differently if you read it as implementator. If the browser exposes only known and "good" ARIA roles then the browser is in good shape and it goes with the spec. The browser can do different approach and expose all ARIA roles (not depending whether they are known or unknown) and let the AT to decide what to do with them. You can argue whether this is a good idea or not but it can be used in the wild, for example, by scripted JAWS and certain web apps (in this case the browser is just a mediator between web app and screen reader). Also the spec doesn't deny that.
However if the browser follows this approach then we run into a problem because the browser must known about abstract roles to ignore them. Abstract roles are pure theoretical matter used to organize stuff in the spec, it's *not supposed* to be used on the web and it *won't* be used on the web but the browser *must* know about them if the browser relies on "expose any role" approach. In reality it slows down the browser for nobody's win. Ok, it's a browser problem. ARIA problem I think is the ARIA spec tries to standardize things that *aren't* supposed to be used on the web what is meaningless in general.
2) aria-checked="mixed" on radios should be mapped to "false" value (see the ARIA spec):
TheI agree mixed value on radios don't make any sense since radios don't support tristate. But the "false" value is not a fallback value on radios. That means the browser *must* introduce a special check for the case that doesn't have *practical* usage on the web.mixedvalue is not supported onradioormenuitemradioor any element that inherits from these in the taxonomy, and user agents MUST treat amixedvalue as equivalent tofalsefor those roles.
The problem is the candidate recommendation means nobody wants to change the spec at this point especially if it's implemented by some browsers already. It doesn't really make sense to address any issue listed above in the next spec since they don't make a difference on the web. It wouldn't be so bad to just follow the spec if we didn't have other discrepancies especially those that *make* a difference for the user.
The reality is either Firefox picks up that burden wordlessly or it gets an yoke of the browser incompatibility with the spec. No good options, huh?
Well, Alex, the bottom line is David Bolter, from your team was part of the working group that defined the UAIG spec. which has always been done in public space. The points you are making is regarding a spec. that has been publicly available to Mozilla and all developers for over a year. I find it difficult to feel sympathetic about the situation. Furthermore, nobody from Mozilla has actually volunteered time to run the actually test and now when we do them you act surprised by the fact that some fail.
ReplyDeleteRich, you're right but I didn't want to blame anyone, just wanted to say something got broken and I'm not sure how to get out of the situation.
DeleteNot to worry. That is why we have Candidate Recommendation test cases. We have lots of browser bugs across the board. We will get them fixed.
DeleteARIA 1.1 will most likely be done in Open Space - we are working on the charter now. I expect Mozilla to be more active this time but the fact that David Bolter has been involved with the public draft since day one I don't know how this will change things for you. Perhaps you should be attending UAIG working group meetings over David as there seems to be a communication problem.
ReplyDeleteI don't know what exact David's responsibilities are as I don't know that for any other ARIA group member but I don't have any doubts it's a hard work.
DeleteHaving me attending UAIG meetings doesn't necessary solves any problems and perhaps I would avoid that but I want to be able to
* see a change log between spec versions (both UAIG and ARIA specs)
* see tests before the spec is closed for changes
* provide and get the feedback
I believe being open is a right step but it won't fix the issue by itself. Obviously there's communication problem and I think ARIA needs a coordinator between browsers, AT vendors and web developers to make sure no single voice is lost.
The level of ARIA engagement I had at the beginning was not sustainable.
ReplyDeleteHaving discussions over a public mailing list along with a searchable public issue/bug tracker is the way to go. I think the live meeting + notes system doesn't make things more efficient in the long term and doesn't allow all time zones equal participation.
Happy to have discussion about improvements but I probably won't comment further on this particular blog.
David, we are going to do that for ARIA 1.1 and beyond. That said. What you are complaining about was not a barrier to you as you had access to the bug tracker and the documents and it was ALL searchable by you. There was nothing prohibiting you from doing what you wanted to do.
ReplyDelete