- From: John Foliot <john@foliot.ca>
- Date: Thu, 8 Nov 2012 22:35:17 -0800
- To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
- Cc: "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'HTML WG'" <public-html@w3.org>
Silvia Pfeiffer wrote: > <snip> > > The discussion about adding the feature to HTML5 will need > to be had around the extension spec so I don't want to go > into this. <snip> > That last argument is the one that browsers don't buy into: > screen reader support for this feature makes a lot of sense. > But browser support less so, because if the author wants users > to be aware of a document that has a long description, they will > author that into the visible part of their Web page. If they > don't they won't author it in. So why should browsers overrule > a Web developer's intention? It goes against what browsers do > and it seems to me that spending more time on pushing such > functionality is futile. Let's solve the real problem which is > accessibility. Hi Silvia, I will politely (but firmly) point out that accessibility != screen readers alone, and yet this continually seems to be a point of misunderstanding in the larger development community. Longer textual descriptions can be of benefit to numerous other users beyond those who cannot see a complex graphic image, including low-vision users (who may prefer a text description over scrolling up and down as well as left and right to try and make sense of a large graphic), users with cognitive disabilities (users with learning/comprehension issues), and when done right can also be useful for SEO considerations. As long as engineers continue to directly link longer textual descriptions to blind users alone, they are missing a significant aspect of the larger accessibility picture. I believe it is incumbent on the members of this Working Group to both understand (or at least try) and promote this idea, not continue to fight against it. You also make the claim that web developers will assume that these descriptions are for non-sighted users only, and while that may be the case for many private developers, there are a whole raft of other developers who will be providing these descriptions knowing and perhaps even wanting that they be available to *any* user who requests them - I can certainly see this as a case in the Education sector - yet must also meet other visual designs important for the majority user-base. There will be others who will possibly be mandated to use @longdesc for regulatory or policy reasons - it's a big web out there. It has repeatedly been pointed out that this could be a browser feature that could be set to "off" by default, yet could be activated by the end user if they so choose: we already have similar features in all of the browsers - for example Firefox allows users to over-ride author style sheets (partially or completely), and Internet Explorer offers a "High Contrast" mode that strips much of the decorative CSS off any page, to name but 2 instances of the end user over-riding the developer/designers visual intent in production today. I am confident that a whole slew of imaginative solutions could be developed if UI/UX designers set their mind to it: we already have a number of browser extensions and plugins that do just that, as well as examples of JavaScripted UI enhancements that could be added by the author that would provide a visual exposure of @longdesc to sighted users, while preserving the core functionality being offered by screen readers. As for "the real problem" today, the intent of Chaals' draft at this time is to capture, confirm and codify what we have on the ground today with regard to support for @longdesc, without imposing any further requirements on the browsers. The goal is to ensure that authors who choose to can continue to use @longdesc and still produce 'valid' HTML5 (per the W3C validator) by making the @longdesc attribute fully conformant. For this reason alone, it should not experience any push-back from the browser vendors, as it has no additional technical/engineering imposition attached to it. If some of those vendors can see the benefit of extending the usefulness of @longdesc to other groups of their users (beyond the non-sighted - as for example Opera and iCab have) then they will make that strategic and business decision - if they don't, they won't, and those users who want to avail themselves to the benefits of @longdesc content will also make their own market decisions accordingly. As I have often said, choice is good. JF
Received on Friday, 9 November 2012 06:35:50 UTC