Re: Revert Request

On 26 January 2012 14:12, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Silvia and Chairs,
>
> On 20th December the chairs said in their review of Jonas' CP, that:
> «this proposal suggests a material change, namely allowing
> aria-describedby to reference hidden elements». And that «this proposal
> should be updated to show that either some use cases cannot be fully
> met without this change, or that some cases cannot be met as
> effectively without this change, or some combination. Otherwise, there
> will be no reason to consider this proposal over the zero change
> proposal».
>
> This review alone, could be enough to ask for a revert.
>
> Note that I tend to agree with Silvia, that from ARIA's point of view,
> then @hidden - as noted in HTML5's ARIA section - is just a synonym for
> @aria-hidden='true'. My reading of ARIA is that it does permit that
> aria-describedby points to an element with @aria--hidden='true'. Like
> Silvia, I'm therefore not certain that the @aria-describedby/@hidden
> change contradicts with @longdesc any more than ARIA as such eventually
> does. A review from the ARIA community to clarify the issue would be
> welcome.

There does appear to be an element of "cutting off our nose to spite
our face" behind this revert request, and this is not the first time
this has happened when discussing ARIA at W3C:

http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0414.html

I think people who are unhappy with this change would be best advised
to actually start discussing the problems they see with it, rather
than sending revert requests which could just end up being a waste of
everyone's time. I think the best place to have these discussions
would be on this list.

> But that said, the @aria-describedby/@hidden change offers an advantage
> compared to the alternative: It is simpler and probably more secure [at
> least in the minds of many site owner] to use compared with the
> alternative, which would be
>      [aria-hidden=true]{display:none}
> However, the consequence of Jonas' proposal would be that *no users*,
> except AT users with ARIA supporting software, would get to see such
> image descriptions. In contrast, it has never been important to the
> @longdesc supporters, that @longdesc content gets hidden from other
> users, rather, we want @longdesc content to be available to all. So
> this seems on its head, when we consider that those in opposition to
> @longdesc often argue that use of @longdesc causes content to be hidden
> from non-AT users.

The change proposal endorsed by the HTML-A11Y-TF (which you were a
member of at the time) clearly regards invisibility as an essential
feature of longdesc. For example:

"[longdesc] does not force a visual encumbrance or default visual
indicator on sighted users. "
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Conclusion

and:

"There is no forced visual encumbrance. This is by design. "
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/UseCases

and 7 of the 10 use cases apparently require the link to be completely
invisible:
http://www.d.umn.edu/~lcarlson/research/ld.html#uc-01

So a non-hidden longdesc would only meet 3 of the 10 use cases
proposed by the HTML-A11Y-TF. This issue has been briefly discussed on
this list before:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0128.html
http://lists.w3.org/Archives/Public/public-html/2011Apr/0131.html

Note this invisibility requirement appears to contradict WCAG2's POUR
principles. If we want to go down that path, the HTML-A11Y-TF should
probably file a bug on WCAG2 to change the acronym to POURI, with the
"I" standing for "Invisible". Or "Imperceivable". Regardless, WG
participants have had plenty of time to submit an alternative change
proposal for a visible-by-default longdesc. HTML-A11Y-TF participants
also had plenty of time to amend Laura's CP before endorsing it.

> Note as well that there is no permission to link to @hidden content,
> and as such @longdesc could not be used to link to @hidden content,
> whereas @aria-describedby could. Why? Is that fair or logical? Or
> perhaps it is @hidden that needs to change? After all, links are often
> 'javascripted' to activate hidden sections. But HTML5 forbids such kind
> of linking.
>
> Also if the zero change proposal, due to its current concurrence with
> Jonas' proposal in this detail, now is considered to reflect what Jonas
> proposed, then should it not offer offer the same use cases as Jonas
> was asked to provide?

It's unclear what you mean here. Could you elaborate?

I don't find any of the 10 proposed use cases convincing, they all
seem artificially contrived to me but clearly opinions on this differ.
So the zero edit CP attempts to address the use cases as if they were
all valid, except for 9 and 10, which in my opinion don't make any
sense and, even if they did, would presumably already be covered by
the alternative techniques suggested for the other use cases.

http://www.w3.org/html/wg/wiki/ChangeProposals/LongdescZeroEdit#Use_Cases

> So, while it *might* be that this issue is not as problematic Laura
> says, it definitely needs to be reviewed. One way - and the most
> logical way - to have that review, is if the editor reverts this change
> and Jonas updates his CP.
>
> Therefore I concur with Laura's request.
>
> Leif H Silli
[crop]

Concerns about this tweak to the spec may be entirely valid, or
entirely misplaced, or motivated by something else entirely, or easy
to address satisfactorily without wasting the editor's, staff and
chairs' time. Until people start discussing their concerns, there's no
way of knowing whether there's anything of substance to be reviewed
here or not. As above, I think people who feel it's important to
discuss this issue would be best advised to actually start those
discussions.

-Matt

Received on Friday, 27 January 2012 10:01:44 UTC