- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Thu, 20 Jun 2013 21:38:01 +0200
- To: public-html-a11y@w3.org, "Michelle McManus" <michelleandremy@gmail.com>
Hello Michelle, On Mon, 17 Jun 2013 16:25:38 +0200, Michelle McManus <michelleandremy@gmail.com> wrote: Thank you for taking the time to write. I have some comments, and some questions that I hope will help me understand your perspective better. > To begin with I am a screen reader user. I enjoy having pictures > described in simple yet concise terms that appropriately fit the context > of the page. I think this is what the alt attribute, or the alt attribute and title, are typically meant to do. In particular, they should be content that you don't mind hearing when you are reading through the page. Longdesc is meant to fill a different case, where you want a more thorough description available, but you probably don't want to have to read through it every time you read the page, or encounter the same image in multiple pages. > If a long description is necessary having a description open in a new > window works well, however, I have found that in a lot of cases this link > is not coded correctly and the description page does not open. Yes, it is known that many authors (and in the past even many tools) have done a terrible job of the coding. One of my assumptions is that the cases where it is done right are useful, and the useless cases are a relatively minor annoyance (you learn not to bother for the bad cases, but you can benefit from the cases where it is done right). > So I prefer either having the descriptions contained within the content > because if the description needs to be long the material probably needs > to be shared with everyone. The specification requires that the description is available to everyone. It just doesn't require that it is physically copied into the same page as the image. > If it is not appropriate to include the description within the > content then it is most likely not needed. Longdesc is primarily intended for descriptions that are not always needed every single time the user reads the page, but where the description is valuable some times. Please note the use cases in the specification, which describe the problems that longdesc solves. Longdesc allows for the case where the description is included directly in the content. It makes it easier to point directly to the description, for cases where it doesn't immediately precede or follow the image. But there are some use cases where it makes sense not to force the description to be included in the page: Sometimes, an image is used in many different places. Instead of forcing the authors to copy and paste descriptions many times, when they will only be used sometimes, allowing all the usages of the image to refer to a description (in the same way that HTML allows all usage of the image to refer to a single source for the image data itself) can save a lot of time and make it much easier to manage a library of content. Sometimes, the default visual presentation of the page is extremely important to the people who are paying for or creating it. To the extent that they will simply refuse to include extensive text describing an image if it interferes with their visual design. Allowing for a reliable way to get that text is important. Despite 20 years of trying, techniques for hiding content except from people who need it don't work, since they also exclude people who do need the content that is hidden. (The "iframe" technique is the most recent example - it works fine for screenreaders, but is completely inaccessible for high-contrast usage, screen magnifiers, people who zoom the content a lot in the browser, and many other adaptations indiciative of people who would benefit a lot from having a long description available). > Thank you. Again, thank you very much for taking the time to discuss this. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals@yandex-team.ru Find more at http://yandex.com
Received on Thursday, 20 June 2013 19:38:33 UTC