- From: Andrew Kirkpatrick <akirkpat@adobe.com>
- Date: Mon, 7 Aug 2006 19:53:00 -0700
- To: <tina@greytower.net>
- Cc: <w3c-wai-gl@w3.org>
Sorry, hit enter too early -- full reply is here. > Would you, please, explain how "Provide a text equivalent for every > non-text element ... this includes ... frames ... " is not clear on > requiring a text equivalent for frames? > > It might be better if "a linear equivalent for frames" had been the > wording, but I see nothing unclear about the checkpoint. What is unclear is what needs the text equivalent. The frame element? The frame element's content? To me it seems that this is referring to the need to provide an equivalent for the frame container, not the content. This is further supported by the existance of the following example in the WCAG 1.0 document: "For complex content (e.g., a chart) where the "alt" text does not provide a complete text equivalent, provide an additional description using, for example, "longdesc" with IMG or FRAME, a link inside an OBJECT element, or a description link." So for basic frames you provide noframes but for complex frames you provide longdesc? Doesn't seem quite right. In fact, the only place that noframes is mentioned in WCAG 1.0 is in 6.5 (Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2]). I, like Bruce, agree that using noframes well is important, but I'd like to be able to point out to developers "here's why you need to do it" if in fact it is required by the guidelines. I feel like I can make the case in WCAG 1.0 but am not sure about WCAG 2.0. AWK
Received on Tuesday, 8 August 2006 02:53:25 UTC