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

I think "relied on" is at the core of the question here.

Because we weren't always consistent in the techniques document code 
examples, I've updated the XSLT to output the following for the extended 
code examples in the Techniques draft:

<p><strong>Example Code:</strong></p>

<pre>
   <code>
     ... multi-line code example ...
   </code>
</pre>

For the places where <code> is used to indicate an element, attribute, 
etc. ("This example uses scripting to add the <code>describedby</code> 
property to user interface controls on the page"), I don't think the use 
of the code element is relied on because the information is available in 
context.

Drew's question is a good reminder that as we work on the question of 
documenting accessibility support, we'll need to be careful to not 
inadvertently discourage authors from using semantic markup, especially 
in places where we'd really like to see the AT begin supporting it.

As long as using markup that is not supported by assistive technologies 
like this doesn't interfere with a users ability to interact with the 
page and as long as the use of that markup is not relied on, there 
should be no reason for us to consider this a failure.

Hope that helps,

-Ben

Andrew Kirkpatrick wrote:
> 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
> 
> 
> 
> 


-- 
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>

Received on Tuesday, 9 September 2008 21:02:31 UTC