- From: Greg Gay <g.gay@utoronto.ca>
- Date: Sun, 07 May 2000 13:28:45 -0400
- To: w3c-wai-gl@w3.org
Anne > I've previously suggested that guideline one specify > that graphics be required as an alternate to text. I'd like to see a > minimum requirement of one illustration be included on a page and that > illustration should be placed so that it is seen when the user first opens > the page. It's only a start of what needs to be addressed regarding > inclusion of graphics so they can aide comprehension of text. I agree that graphics are a must on web sites, however there are limits to what we can ask web developers to include in graphical form. I also agree with your observation, and WL's, "*unexplained* visual aids might be as confusing (difficult) and frustrating". I think an approach like guideline (14.1) can be applied here, when it's wording clearly reflects the nature of the site's audience and the appropriate use of alternative formats: Depending on the Audience 14.1 (P1) Use the clearest and simplest language appropriate for a site's content 14.4 (P1) could read: Use multiple formats appropriately to aid comprehension, suitable for a site's content and audience. For example, a site intended for those with cognitive disabilities should include plenty of visual (and auditory/text) alternatives, while a site intended to convey scientific information (eg. an online paper) should only include a few visual aids to improve comprehension for important or difficult points. Gregg mentioned ".. there will be some groups of people with cognitive [disabilities] that will never be able to use a web page even if you did everything to it." and, "there are some types of information on the web that we can never really make accessible to people who are blind." I believe his point is that we can never really expect Web designers to accommodate every last person who might visit a site, but we should expect them to adequately accommodate the intended audience. This will be an important point in formulating guidelines for providing accessibility for those with cognitive disabilities. http://lists.w3.org/Archives/Public/w3c-wai-gl/2000AprJun/0252.html Navigation vs Content You can also distinguish between graphics that are navigational elements and those that are content; generally, the first is functional and the second is a unit of knowledge. In cognitive lingo, one is procedural and the other is declarative. At one level developers can be asked to include visual navigation tools that provide visual cues (e.g.. icons, buttons, image maps) or structure the content of the site into a form that can be visualized ( e.g., a site-map, index, table of contents). At a second level developers can be asked to include visual alternatives for content. On the one hand concrete content, such as directions for assembling something, is relatively easy to create, but on the other hand abstract content, such as a definition for "liberty", are not easily created or effectively conveyed in a visual format. We can't "require" designers to provide visuals for abstract content, and how much of the concrete content should include visual alternatives will be difficult to agree upon. We will have more success asking designers to include visual navigation alternatives, since navigation tools are generally created only once. The amount of work involved in creating alternative navigation systems will be much less than that required to create visual alternatives for content. As Gregg mentioned, currently "P1 P2 and P3 are based entirely on the degree of access they provide and not at all on ease of implementation." For this reason using alternatives for navigation should be a higher priority than including alternatives for content. 14.4a (P2) could read: Use redundant alternative navigation, appropriate for a site's content and audience (buttons, icons, text links, image maps, sitemap, index, search) 14.4b (P3) could read: Use redundant alternatives for content, appropriate for a site's content and audience (audio, video, images, text) (14.4a could fit into guideline 13, and 14.4b could fit into guideline 1) > > Regarding TTS, as long as it doesn't properly render boxed text/tables, > doesn't allow visual access to graphics/text while the text is read, and > remains too hard for folks with normal hearing to understand, it shouldn't > be considered a significant accommodation for LD/CD folks. Citing TTS > suggests the problem has been solved, when in fact it does no such thing. I disagree with your opinion that TTS is not an important accommodation. Perhaps not for everyone, but definitely helpful for many. Many of the college age LD students I have worked with use it regularly, not to mention a variety of useful tasks TTS can be used for, for anyone (e.g.. proof reading, multi-tasking, a preschool reading teacher,... ). Marshall Raskind has conducted numerous studies that show how TTS benefit those with LD. Perhaps a less rigid approach would be more effective. Such as "TTS is helpful for a portion of those with LD, those with auditory and verbal processing intact, but will be less useful to those who's cognitive disability is rooted in either one of those processes." I also agree with the reasoning, outlined by Jason, that part of the responsibility should be placed on the developers of adaptive technology to design their products to process components such as tables. It would be unreasonable to ask Web designers to give up using tables to format layout. I think however, that layout of text in tables should receive a priority 2 ranking, since from the view point of adaptive behaviour, comprehension is improved with a simplified and consistent layout (see guideline 13), and with the current state of these types of programs (i.e.. TTS), few of which read table correctly, changing these programs will be a more difficult undertaking than for their developers, than asking Web designers to provide linear formats readable by current TTS programs. Once the TTS developers have "caught up", as most screen reader developers have, the priority can be reassigned a P3 ranking. >
Received on Sunday, 7 May 2000 13:33:46 UTC