Re: Description link consensus

Hi Leif,

> I sent this letter only to the A11Y TF. Because I have consensus within
> the A11Y TF in mind.

I understand that, Leif.

> May be you should ask those in the A11Y TF that
> disagree with you, about whether what I outlined could be something
> they could consent to?

I imagine some could. I understand that a very high number of task
force members have vested interests in ARIA. However, this is the
HTML5 Accessibility Task Force.

Our objective is: "to help ensure that HTML 5 provides features to
enable Web content to be accessible to people with disabilities. This
includes review of existing features for potential accessibility
problems, and proposal of new features where needed." [1]

The question I would ask HTML5 Accessibility Task Force members is if
they agree to lose the opportunity to provide a native HTML5 long
description feature for other elements besides <img> and agree to
shirk off that responsibility to a future version of ARIA.next (a
bridging technology [2]) or shirk off that responsibility to
HTML.next, which like ARIA.next not only has no definitive timeline
but also no definitive membership and no charter. (Thank you Philippe
for your honest answers [3].)

I ask, is it not dereliction of HTML5 Accessibility Task Force duty?
How does it ensure that _HTML5_ provides a long description feature to
ensure Web content is accessible to people with disabilities on
anything besides <img>? My fear is that the proposed compromise
compromises HTML5 accessibility.

Or do people agree that no use cases exist in HTML5 for long
descriptions on anything other than <img>? i.e., table summary, and
video, etc. and that the task force has fulfilled its job? If no use
cases exist maybe we have it covered and I worry for nothing.

Best Regards,
Laura

[1] http://www.w3.org/WAI/PF/html-task-force#objective
[2] "Note that WAI-ARIA is intended to be a bridging technology. It is
expected that, over time, host languages will evolve to provide
semantics for objects that currently can only be declared with
WAI-ARIA." - PFWG Charter.
http://www.w3.org/WAI/PF/charter201006
[3] http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0345.html
[4] http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0327.html

On Thu, Mar 22, 2012 at 1:13 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> The describeAT draft:
>
> Rich and Steve's draft for describedAT was released after my CP to
> extend @longdesc to embedded elements with the role 'img'. Their draft
> could be a reason for me to back off my CP, and for us all to instead
> give full support to  Laura's CP to get @longdesc for the img element.
>
> Camels to swallow:
>
> Some in the A11Y TF think @longdesc should be obsolete but conforming.
> Others want a two-step process where longdesc becomes valid for <img>
> first, and then extended to more elements. My own CP suggests to extend
> longdesc immediately, to embedded elements of role 'img'. The sweet
> spot - the compromise solution - seems to be to support Lauras CP and
> thus support @longdesc as fully conforming, and also not try to have
> any two-step process within HTML5. A way towards consensus, is to
> postpone the questions we can postpone, to HTML.next. May be one wants
> to reevaluate longdesc in HTMl.next or when ARIA1.1 is out. And also,
> possibly evaluate whether - in HTML5 - aria-describedAt should be valid
> on any element. But we don't need to decide this now. In fact, we can't.
>
> Impact of describedAT:
>
> On one side - the ARIA-describedAT draft, is a good step which will
> support Laura's @longdesc proposal - as it stands. That is: For the
> <img> element.  Also, by making longdesc specific to <img>, there might
> be a chance for deeper integration with that particular element - e.g
> as outlined in my comment on the Webkit bug:
> https://bugs.webkit.org/show_bug.cgi?id=10448#c6
>
> On another side - the ARIA-describedAT draft does as well not encourage
> the extension of longdesc to more elements, for instance because it
> seems unlikely to me that we will get longdesc support for new elements
> any earlier than we get aria-describedBY support.
>
> On the third side: If the two attributes effectively ends up as
> essentially the same feature , then, unless the two specs - HTML5's
> longdesc spec and ARIA 1.1's describedAt spec -  are aligned, then
> implementors might avoid implementing @longdesc and instead wait for
> the final word on aria-describedAT. I don't mind if the implementation
> of @longdesc takes color from the @desscribedAT implementation. But
> there are some important details that should be agreed upon.
>
> Current feature differences:
>
> A difference between Rich/Steve's draft and Laura's CP, is the latter
> emphasizes 'no visual encumbrance' whereas Rich/Steve say that there
> SHOULD be a visual indicator on [I think] the page. Perhaps the
> describedAT draft should leave it to the host language what to do by
> default? Or should @longdesc and @describedBY differ in that detail?
> This needs clarification.
>
> Another difference is that longdesc is only used for embedded content -
> images, iframes and frames in HTML4, whereas describedAT applies to any
> content - even elements which typically do not have any context menu
> [typically only embedded content has context menus]. Perhaps the
> describedAT draft should say that it depends on the host language
> whether a contextual menu is shown?
> --
> Leif Halvard Silli

-- 
Laura L. Carlson

Received on Friday, 23 March 2012 17:07:59 UTC