Re: ISSUE-199: aria-processing - Chairs Solicit Alternate Proposals or Counter-Proposals

On Tue, Feb 21, 2012 at 12:45 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> 'Define complete processing requirements for ARIA attributes'
> The current status for this issue:
>
> http://www.w3.org/html/wg/tracker/issues/199
> http://dev.w3.org/html5/status/issue-status.html#ISSUE-199
>
> So far, we have one Change Proposal submitted:
>
> http://www.w3.org/html/wg/wiki/ChangeProposals/ARIA_Processing
>

Finally had a few minutes to review this proposal. It has a number of
issues.

- It reiterates concepts like "valid role token" and relevant deferences to
WAI-ARIA multiple times in slightly different ways, leading to confusion as
to the actual meaning.
- It allows roles that are not defined, instead of defining the allowed
role by deferring to the latest version of ARIA. (But it claims this is for
forward-compatibility, despite it not being a UA conformance criteria, and
then puts "SHOULD NOT" level requirements on author's thoughts, allows
conformance checkers to warn about these errors anyway, and then
contradicts itself by saying that even though invalid roles are allowed,
they're "reserved" and "SHOULD NOT" be used — this all takes about two
paragraphs when the whole thing could be wrapped up cleanly in one sentence
by deferring to the latest version of the roles definitions.)
- It defers to a "data" attribute that doesn't exist.
- It allows multiple values but says that all but the first are discarded.
- It partially defines ARIA processing, but does not do so rigorously.
("For ARIA processing, the role ... is the first token whose name literal
matches a ... WAI-ARIA role" — what is "the role", what is a "name
literal", what does "matches" mean?) This should instead be done via a
direct reference to the relevant hook in the ARIA spec.
- It mentions, without defining, two presumably new IDL attributes,
including one that, if defined consistent with other similar attributes,
would be relatively expensive yet does not appear to serve any useful
purpose (roleList).
- It contradicts itself with regard to ARIA state and property attributes,
both allowing them on elements without role="" and requiring that some
(exactly which is not apparently defined) be used only with role="".
- It redefines or relists all the ARIA state and property attributes
explicitly, redundantly repeating information in the ARIA spec. This is
pointless and can only be a source of errors. Instead it should define
these attributes, if that is necessary at all, by deferring to ARIA.
- In general the entire approach seems backwards. Why would ARIA be treated
differently than SVG or MathML? We don't redefine the entire SVG and MathML
vocabularies in the HTML specification, we just import them. ARIA should be
handled in the same way.

I don't have time to write a thorough CCP, though a trivial one is included
below pro forma. Should this issue be handled according to our process
(i.e. by not having escalated it, since the original request was never
rejected in the first place), I would be happy to edit the spec so as to
say what the proposal is trying to say, but without the problems listed
above.


CCP for issue 199
SUMMARY: No change.
RATIONALE: No bug has been rejected.
DETAILS: No changes as part of this issue; changes can be performed as part
of normal bug resolution.
IMPACT: None.

-- 
Ian Hickson