RE: Is it a problem that WCAG 2.0 doesn't require paying attention to NOFRAME content?

Hi Tina (et al.),

I note that Andrew Kirkpatrick and Johannes Koch have also responded.  As usual, both of them are more succinct than I!  But I had this reply mostly done, so I finished it, and I am posing anyway!

I regret giving this thread such an inflammatory subject line that leads the question.  I think it is worth the time to discuss some of the premises.

At what level does WCAG 1.0 require robust noframe content?

Under what circumstances does WCAG 2.0 require robust noframe content?

Clearly Tina, you believe robust noframe content to be important.  Does WCAG 2.0 serve that end to your satisfaction?  If not, what would need to be changed?

Tina wrote:

> You are indeed mistaken.  WCAG 1.0, level 'A', checkpoint 
> 1.1 requires that text /equivalents/ be provided for 
> frames - that is equivalent content/navigation.

I am aware that such assertions have long been made by some.  I find the arguments in support of such a view to be unconvincing.

(1)  The verbatim wording from 1.1 reads <q>for example, "longdesc" with IMG or FRAME</q>.

Which is no help since longdesc attribute on FRAME elements was never supported and dropped for XHTML.

Following the link for <q>Techniques for checkpoint 1.1</q> includes <q>Describing frame relationships</q>.  Following that link to the HTML Techniques document gets us to additional clarification for 1.1 which reads <q><em>This includes:</em> [snip] frames [snip]</q> where frames is mentioned in a long list of about sixteen other items.

The next paragraph reads in whole:
<blockquote>
12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. [Priority 2]
</blockquote>
http://www.w3.org/TR/WCAG10-HTML-TECHS/#frame-text-equivalent

Plainly, WCAG 1.0 Single A allows for good frame titles *only* -- at least when the purpose of a frame is obvious from its title.

(2)  It is, to say the very least, a stretch to assert that a requirement for text equivalents applies to (nominally) text-oriented elements (like FRAME).  This is the same point that Andrew and Johannes raise.  On the other side, the Access Board made a similar equivocation as to why 1.1 applies to PDF. 

(3)  Why have 12.2 if 1.1 if already requires robust NOFRAMES content?  Obviously, P2 12.2 is meant to require something *in addition to* the P1 checkpoints. 

(4)  The draft mapping from WCAG 1.0 to 2.0 for 1.1 contains:  <q>For framesets, noframes is no longer required.</q>  For 12.2, <q>This is no longer required for conformance</q>.
http://www.w3.org/WAI/GL/WCAG20/appendixD.html

Received on Monday, 7 August 2006 13:31:44 UTC