Re: [text] minutes: Text Alternatives Subgroup 2011-04-18 [draft]

Hi all,

On 4/18/11, Gregory J. Rosmaita <oedipus@hicom.net> wrote:

>   JB: who has read all 3 of these in detail

I have studied all three decisions, especially the longdesc decision.

The number one strongest deficiency in the previous rejected change
proposals for longdesc, summary, and posteralt was lack of
communicating specific use cases. It seems that the HTML Chairs did
not understand WHY these accessibility features are needed. We may
have thought that we articulated the use cases but it seems from the
decisions that we did not.

>From all three decisions:

1. QUOTE table-summary decision [1]:

"This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* Identification of specific use cases, along with a number of
specific examples from real-world sites, where a separate table
summary would be useful either instead of or in addition to a caption
element or an aria-describedby attribute. Ideally such use cases would
explain why this is needed only for tables but not also for images or
canvas elements which could express the same information using a
different mechanism..."


2. QUOTE poster-alt decision [2]

"This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* Identification of use cases that specifically require a different
description for the placeholder/poster/firstframe image than for the
video itself. These use cases would need to cover every normative
requirement identified in any Change Proposal which might accompany
the request to reopen the issue based on new information. Ideally
evidence for these use cases would be provided in the form of real
world deployments of videos on the web..."


3. QUOTE longdesc decision [3]:

"This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* use cases that specifically require longdesc... "

We have a distinct pattern.

This is why we have been working very, very hard on writing new formal
use cases for the longdesc change proposal.
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#New_Formal_Use_Cases_Requiring_longdesc
I hadn’t written formal use cases before this and did a bit of
studying on the subject. For an explanation of use case elements,
please consult the Use Case Key.
http://www.d.umn.edu/~lcarlson/research/usecasekey.html


4. It seems to me that previous task force rejected change proposals
were rejected based on rationale that includes but is not limited to
the notions that:

* Other features provide needed functionality.
* Accessibility features can be measured by mainstream metrics.

This is why we have the other sections in the InstateLongdesc change
proposal regarding Suggested Alternatives Are Not Viable Solutions,
New Usage Information, 80/20 Rule sections of the change proposal [4].

>   longdesc, table summary, etc. may evolve, move to ARIA as a stronger
>   mechanism

As for longdesc, ARIA is not viable:
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#aria-describedby
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#aria-describedat

ARIA for table summary would be burdensome. Someone recently said to
me that, "using ARIA as a workaround for a table summary would be way
too cumbersome. No one would want the text on the screen, as it would
state what is visually evident. So to use ARIA, a developer would have
to write the content, hide it with CSS, and then reference the hidden
text with aria-labelledby. That's so cumbersome that surely even the
most enthusiastic ARIA supporter would realise that the summary
attribute is far more efficient and already well-supported." I agree.

>   <oedipus> JF: 1 thing mentioned was moving some of these things into
>   ARIA as new "home" for evolution of accessibility solutions -- want
>   to express concern about that -- backwards move to push a11y on ARIA
>   -- ARIA bridging tech until needed native semantics provided by ML
>   devs; concerned moving in backwards directtion; ARIA is not the
>   savior/only solution

+1

>   some say that it might be better to have an attribute that has
>   greater reach - could be used with canvas etc.

It is possible that longdesc could be expanded to other use cases.
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Expanding_longdesc_Use

However, "The strongest argument against inclusion was the lack of use
cases that clearly and directly support this specific feature of the
language." [3]

>   JB: one thing to note is that changing the way a11y is being
>   designed due to appeasement is a bad way to design

+1

>   JB: not a 'diss' on ARIA
>   ... one of the things I am wondering is I hear people express
>   different opinions and map against requirements
>
>   hear concerns about cross UA support from GJR and JF

The simple truth is that most web designers are not going to learn
ARIA. They consider it foreign. Bolt-on. If the ARIA prefix was
removed, it might be more palatable. I don't know.

Today's alt ISSUE 31 decision talks about aria-labelledby as being
redundant with other constructs. The decision disallowed it as a valid
replacement for alt.

ARIA for longdesc is also redundant. It reinvents the wheel.

>   there is a body of @longdesc content in existance already

Yes.

But beyond this, it is just not content. longdesc is also recognized
by existing authoring tools, user agents, assistive technologies,
educational material, etc. It has a critical support base that has
taken a decade to build and would probably take another to rebuild
with something else. Something new would setback progress.

Reasons why longdesc should be reinstated into HTML:
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Conclusion:_longdesc_Should_be_Included_in_HTML5

These are all detailed in the change proposal.

>   <oedipus> doesn't HTML5 have a mandate about backwards compatibility

It is one of the original design principles, Gregory. HTML is keeping
things like <u> and <i> and <b>. So it is illogical to be obsoleting
longdesc and summary.

>   RS: the thing I had the biggest issue with is that I agree that
>   dumping @longdesc completely is a problem
>
>   we need a deprecation strategy

On this we disagree.

We need to improve longdesc. We are attempting to do this by improving
the spec text.
http://www.d.umn.edu/~lcarlson/research/ld-spec-text.html

Ideas to improve the two bullet points that start with:

* Conformance checkers and authoring tools...
* User agents...

would be very much appreciated. Thanks.

Best Regards,
Laura

-- 
Laura L. Carlson

[1] http://lists.w3.org/Archives/Public/public-html/2011Apr/0091.html
[2] http://lists.w3.org/Archives/Public/public-html/2011Mar/0690.html
[3] http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html
[4] http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#toctitle
-- 
Laura L. Carlson

Received on Tuesday, 19 April 2011 00:43:17 UTC