- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Wed, 18 Apr 2012 22:17:29 -0500
- To: David MacDonald <david100@sympatico.ca>
- Cc: 'WCAG' <w3c-wai-gl@w3.org>, 'Loretta Guarino Reid' <lorettaguarino@google.com>, 'Joshue O Connor' <joshue.oconnor@cfit.ie>, 'John Foliot' <john@foliot.ca>, 'Cynthia Shelly' <cyns@microsoft.com>, 'Richard Schwerdtfeger' <schwer@us.ibm.com>, 'James Nurthen' <james.nurthen@oracle.com>, 'Janina Sajka' <janina@rednote.net>
- Message-id: <7B3106A6-BEB6-4E38-BA74-A2F2389893E0@trace.wisc.edu>
Hmmm I see what you are getting at. But Longdesc is a viable technique and puts the alternate form of information in a graph on another page - linked to from the first page. If we adopt that strict approach then longdesc was always a violation. So having the menu on another page would not (to me) look like it was totally unprecedented. Interesting. Gregg -------------------------------------------------------- On Apr 18, 2012, at 4:12 PM, David MacDonald wrote: > Wondering about other's opinions on fallbacks for inaccessible Javascript > drop down menus, where the top of the menu is a normal link, but the > dropdown items below them are not accessible. However, all the links in the > dropdown are repeated as normal links on the destination page. > > Strictly speaking WCAG Conformance criteria 2 requires the entire page be > accessible, > > http://www.w3.org/TR/WCAG/#conformance-reqs > > Success Criteria 2.1.1 requires "all content is operable through a keyboard > interface." > > So placing fallbacks for specific widgets at a separate URL raises > questions. It appears we have not addressed this type of fallback explicitly > in WCAG ... But of course Longdesc provides an alternative for the image on > another page and in that respect is a precedent for providing a fallback at > a separate URL ... in WCAG we didn't say longdesc is an exception. So I'm > torn on the Javascript dropdown fallback. > > Do we fail these dropdowns (which have a fallback at other URL) and require > them to make the dropdown accessible (which is now possible)? Or do would we > say it's sufficient alternative? > > Cheers > David MacDonald > > CanAdapt Solutions Inc. > "Enabling the Web" > www.Can-Adapt.com > > > -----Original Message----- > From: Janina Sajka [mailto:janina@rednote.net] > Sent: April-18-12 4:27 PM > To: Laura Carlson > Cc: Joshue O Connor; John Foliot; Cynthia Shelly; Judy Brewer; > david100@sympatico.ca; Richard Schwerdtfeger; James Nurthen; Leif Halvard > Silli > Subject: Re: WAIT, hang on... (was RE: Revised Issue-204 Draft from Cynthia) > > Hi, Laura: > > I think we're now crossing emails as we actively look at this. I've just > sent an email that addresses much of what you say here, so I won't repeat > that other than to suggest that your points #3 and #4, while absolutely > important and correct, are really I-30 points, and not necessarily I-204 > points. > > > We have previously complained, all of use have variously complained to the > HTML Chairs that they only complicated and postponed the resolution of I-30 > when they created I-204. While they were wrong to do that, we need to be > particularly careful to stay on topic, lest we lose out for out of scope > argument. > > But, please see my other email. > > Janina > > Laura Carlson writes: >> Hi Janina, >> >>> Also, you should know that PF spent the entire weekly telecon >>> perfecting Cynthia's CP today. There may be more tweaks this >>> afternoon, so please refresh. >> >> I have reread Cynthia's CP. The main point is lost in the added >> verbiage from Matt T's proposal and UAIG. >> >> I recommend: >> >> 1. Removing Matt T's use case text. He has already said it in his own >> proposal. No point in repeating it. >> 2. Moving the UAIG info to a sub-page as I did or just link to the page I > made. >> http://www.w3.org/html/wg/wiki/ChangeProposals/CorrectHidden/UAIG >> Sub-pages were great for focusing the longdesc CP. If there are other >> sub-points they can be linked to too. >> 3. Emphasizing repercussions in the spec text. Flat out say: >> "This technique should not be used for longer descriptions that have >> structured text (e.g., headings, anchors, list markup, table markup, >> etc.), as rich text is stripped to string text, resulting in all >> semantic structure being lost." >> 4. Emphasizing repercussions in the risks section. Flat out say: >> "It will lead to a very poor user experience if this technique is used >> for longer descriptions, as reading keys will not work. Users will not >> be able to interact with the content. All links will be dead." >> >> In short clear out the baggage. And don't sweep number 3 and 4 under >> the rug. For everyone's sake keep 3 and 4 prominent. >> >> These changes would be consistent with my CP. >> >> Thanks. >> >> Best Regards, >> Laura > > -- > > Janina Sajka, Phone: +1.443.300.2200 > sip:janina@asterisk.rednote.net > > Chair, Open Accessibility janina@a11y.org > Linux Foundation http://a11y.org > > Chair, Protocols & Formats > Web Accessibility Initiative http://www.w3.org/wai/pf > World Wide Web Consortium (W3C) > >
Received on Thursday, 19 April 2012 03:18:12 UTC