- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Mon, 18 Apr 2011 19:42:48 -0500
- To: HTML Accessibility Task Force <public-html-a11y@w3.org>
- Cc: "Gregory J. Rosmaita" <oedipus@hicom.net>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
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