RE: Question on <pre> and <code> - violation of 1.3.1?

Unfortunately this is not how it is currently working in the WCAG 2 document.  There can be a perfectly semantic construct in an XHTML or HTML document, but unless you show that it works with current AT, that semantic construct is not accessibility supported and wouldn't be able to be relied on.

This will also potentially put other HTML elements at risk for not being able to be used, including ones like optgroup and table elements like THEAD, TFOOT and some table attributes for which support is poor, along with <del> and <strike> and ones Jared mentions.

Thanks,
AWK

Andrew Kirkpatrick

Senior Product Manager, Accessibility

Adobe Systems

akirkpat@adobe.com


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Jared Smith
Sent: Friday, September 05, 2008 4:03 PM
To: w3c-wai-gl@w3.org
Subject: Re: Question on <pre> and <code> - violation of 1.3.1?


On Fri, Sep 5, 2008 at 9:12 AM, Tina Holmboe <tina@greytower.net> wrote:
>  Correct. It's a cooperative effort between content creators, spec
>  manufacturers, and browser writers - if we don't ALL cooperate we ALL
>  lose.
>
>  In this case the specification is there, the document authors has done
>  their job, now the AT writers must do theirs.

Precisely.

If a failure is quantified by the ability for user agents to support
and identify an underlying element, then there are much bigger issues
than just <code> that would introduce failures. <strong>, <em>,
<blockquote>, <cite>, and a host of others would most notably fail
because they are largely ignored and not identified distinctly from
surrounding text - though there's no reason why they couldn't be. The
reverse could equally be applied - why require associated labels for
adjacent form elements when screen readers already auto-associate
them. User agent support cannot be the whole measure of these
criterion.

Jared Smith
WebAIM

Received on Tuesday, 9 September 2008 20:05:25 UTC