- From: John Foliot <john@foliot.ca>
- Date: Sat, 6 Sep 2014 09:44:15 -0700
- To: "'James Craig'" <jcraig@apple.com>
- Cc: "'Janina Sajka'" <janina@rednote.net>, "'Joanmarie Diggs'" <jdiggs@igalia.com>, <public-html-a11y@w3.org>
James Craig wrote: > > >> 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 > > The longdesc attribute is not content. The longdesc attribute is just > one of many ways to associate two pieces of content. The more ways you > associate or provide that content in a variety of formats, the more > robust it will be. Then James, using that line of reasoning: a) the longdesc attribute can link to a fully conformant, fully marked up, semantic *and thus robust* document that provides a longer description of a complex image. b) "The more ways you associate or provide that content..." - which means that support for conformant @longdesc is *one more way* of supporting the provision of long descriptions, in addition to the number of ways you have advocated to date. This specification in no way suggests that it is the only way, nor even the "preferred" way, of providing a longer text description. It *does* seek to keep an established, decade-plus attribute conformant in validators when used in an HTML5 document, and makes access to this information that much more robust, because we're providing yet "one more way". > > > > 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)? > > I am suggesting that any and all W3C specs should encourage authors to > provide robust content. Would you still oppose the proposed text if we > removed the word "longdesc" and replaced it with something else? Once again, you are mixing your own definition of robustness. At the end of the day, yes, we should be encouraging content authors to provide "robust" content to all users, which means that complex images SHOULD also contain textual equivalents for those users who need or prefer that content. What you seem to be opposing is *how* that textual content be associated to the image, yet earlier you suggested that the more ways the better. We have content publishers (Pearson) and instructional providers (DIAGRAM Project) who are both teaching content creators about the need for, and the means of, both writing those longer descriptions (the harder task BTW), and on how to associate that content to the images. These parties also recognize that "the more ways the better", but that sometimes they cannot impose any visual encumbrance on the on-screen content. In that case, one way to provide the content is to use @longdesc - it has good if not ideal support already, and if the browser vendors seized the opportunity, they could make that support better. > > Modified: > >>>> Authors MUST NOT rely on *any* specific feature as the sole means > >>>> to provide access to information which is essential for the user. Right, which by extension could also mean then that I cannot *solely* rely on MathML (today) - a comment educators have already made to this working group. We cannot rely *solely* on accessible SVG today - as user-agent support is extremely weak. In fact, we cannot rely *solely* on any of the alternative techniques you have suggested, for a variety of reasons, including the fact that design considerations are a factor that content creators cannot dismiss with a wave of their hand. This comes back to your point of *choice*, and removing a choice, rather than accepting its existence in the wild (and earlier specifications) and improving on its user-agent support, is a step backwards. > > Longdesc is known to not be supported for any users in Chrome and > Safari, and only supported for assistive technology users in Internet > Explorer. (No need to link to the polyfills again. I've seen them.) Actually, Chrome + ChromeVox provide support for longdesc, and Firefox + NVDA, JAWs and now Orca also provide support. The fact that native support for sighted users remains woefully poor is not discounted, but like accessible MathML and accessible SVG, we (*I*) remain hopeful that support will increase. > Regardless if we agree on longdesc being a *good* feature, it is just > one not-particularly-well-supported way to associate content. > Therefore, it's wise to recommend that "essential" content MUST or > SHOULD be associated in a robust way in addition to longdesc. This seems to be the crux of your argument. The thing is, you seem to be very quick to discount the fact that for one significantly affected user-group - those who cannot see the image - support from their "user-agent stack" is actually pretty robust on both the Windows and Linux platforms. And while I would love to see a more robust support solution emerge native to all the browsers, for sighted users who would benefit from @longdesc linked content, for those sighted users who already need this type of on-screen support we *do* have multiple browser extensions that address their need. By using both a browser and an additional piece of software, a workable (if not ideal) solution exists. This is similar to literacy aid tools, that both read aloud and visually highlight text on screen (see: Read/Write Gold), a solution that appears to be acceptable to both the user groups, and apparently the majority of browser vendors as well, who have no qualms handing off "accommodation" support like this to third party "bolt-on" tools. (Yes, I know that this feature is also native to iOS, but not other platforms. However neither Apple nor the W3C are in a position to mandate that either, and so for many users, they *do* bolt on third-party software, apparently with little ill effect.) Yet somehow, you wish to hold @longdesc linked content to a higher standard, arguing an all-or-none position. I will argue that it is an unrealistic position to be taking, but it is also apparent you disagree. > > > > An extremely simplistic answer to a complex problem statement - > > personally it leads me to question if you even fully understand the > problem statement. > > It's a simplistic (but nonetheless true) answer because we've hashed > and rehashed the detailed answers for over 7 years. And even though you have repeatedly been given detailed answers as to why such a simplistic solution is unrealistic, you continue to advance it - deaf to the feedback and responses you've been given over 7 years. > I don't need or > wish to spend any more time on it. You've repeatedly questioned our > intelligence and integrity on this matter, but the objection is founded > in a fundamental belief that the bolt-on "separate but equal" approach > is bad for accessibility. Integrity demands we oppose it. One can only hope then that should @longdesc become a fully conformant part of the HTML5 specification, that the very same integrity you speak of will find a way of providing support for the attribute in the user-agents you are involved with. Given your employer's history of surfacing elegant and integrated solutions to other tricky UX problems, you stand a real chance of one again blazing forth with an imaginative solution. JF
Received on Saturday, 6 September 2014 16:44:48 UTC