- From: John Foliot <john@foliot.ca>
- Date: Wed, 3 Sep 2014 13:19:52 -0700
- To: "'James Craig'" <jcraig@apple.com>, "'Janina Sajka'" <janina@rednote.net>
- Cc: "'Joanmarie Diggs'" <jdiggs@igalia.com>, <public-html-a11y@w3.org>
James Craig wrote: > > > > > YOUR COMMENT #1: > >> Proposed Additions to "3.0.2 Authors" > >> > >> * Authors MUST NOT rely solely on longdesc as the means to provide > >> access to information which is essential for the user. > > > > DISPOSITION: Not accepted > > I understand Joanie's comment on behalf of Igalia to be in line with > Principle 4 of the Web Content Accessibility Guidelines: > > WCAG Principle 4: Robust - Content must be robust enough that it can be > interpreted reliably by a wide variety of user agents, including > assistive technologies. As I understand it, the longdesc attribute *CAN* be reliably interpreted by a wide variety of user agents (http://www.d.umn.edu/~lcarlson/research/ld.html#browsers), including many assistive technologies (http://www.d.umn.edu/~lcarlson/research/ld.html#at). The fact that the reliability goes down significantly on 2 related operating systems is unfortunate, but in-and-of-itself not a reason to halt progress on longdesc. Reliably does not equal universality. > > WCAG Guideline 4.1 Compatible: Maximize compatibility with current and > future user agents, including assistive technologies. Research has already proven that compatibility with current user-agents is itself robust, if not universal. > > Whether a longdesc is essential or nonessential will depend on > > circumstance. It will vary among users, and will even vary for the > > same user given different circumstances. > > The original comment was about requiring AUTHORS to provide robust > content for the sake of these USERS. The HTML-A11Y group may have > overlooked this point. I assume this response was only discussed in a > conference call; I didn't see it discussed on the email list or I would > have pointed this out. I am not clearly understanding your comment here. Are you suggesting that AUTHORS shouldn't provide "robust content" (my interpretation of that phrase = detailed longer descriptions when appropriate)? In fact, I am unsure what point you are actually trying to make here. Could you kindly elaborate? > > > The point of the longdesc feature is to make it easy for the user to > > access that information, or to readily skip past it as their needs of > > the moment may dictate. > > There are a number of ways to achieve this, including using a standard > link. An extremely simplistic answer to a complex problem statement - personally it leads me to question if you even fully understand the problem statement. I urge you to revisit the original Requirements statement (http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#User_and_Aut horing_Requirements), and specifically the following: User Requirements: No forced visual encumbrance - The user MUST be able to configure the longer description mechanism to be visible or not, according to their needs. Author Requirements: No forced visual encumbrance - By default the long description or long description indicator MUST not force a visual encumbrance or impact the visual user experience. This concern for how adding a longer text description (links) will impact the final design is not unfounded: close to 25% of screen reader users [1] and nearly 15% of dedicated web accessibility professionals [2] cite the impact on look and feel of a web page as a barrier in achieving an accessible page. [1 - http://webaim.org/projects/screenreadersurvey5/#reasons] [2 - http://webaim.org/projects/practitionersurvey/#reasons] Repeatedly telling us the answer is to just put it in a link completely ignores this issue. That isn't addressing the issue James, that's dismissing it as non-valid. Given that we have demonstrably significant numbers to bolster the validity of the problem, it needs to be addressed. Does this then place the responsibility on the browsers to actually get this something close to "right"? You bet. We already have a number of proofs of concepts (via browser extensions and scripted "plugins") that have led the way in illustrating how that support *might* look like in the GUI. From my vantage point however, this will come down to a user-togglable setting in the browser, similar to the current abilities to over-ride font settings, link colors, invoke high-contrast, disable images, and numerous other "display" property modifications that *individual users* can choose to apply to their personalized "user-agent stack". The fact that this seems to be such a stretch to the creative thinking of the UI designers at the various browsers continues to confound and perplex me. JF
Received on Wednesday, 3 September 2014 20:20:22 UTC