Re: conformance levels [was: Re: alt crazyness ...]

sorry missed a key "not" in this sentence:

- if we do *not* stamp code as 'compliant html' (due to accessibility
issues) then authors/developers may give up on compliance altogether.

i.e. @alt raises the compliance bar ... there are pros and cons
associated with that.


On Mon, May 5, 2008 at 1:03 PM, Ben Boyle <benjamins.boyle@gmail.com> wrote:
> On Mon, May 5, 2008 at 5:18 AM, Jim Jewett <jimjjewett@gmail.com> wrote:
>  >
>  >  Olivier GENDRIN reminded us of
>  >  http://www.w3.org/TR/WCAG20/#conformance-claims
>  >
>  >  and Smylers wrote:
>  >  > That has two levels of conformance, with a 'partial
>  >  > conformance' exception for included external content.
>  >  > Are you suggesting something similar for HTML 5?
>  >
>  >  Yes; there has been resistance in the past to multiple levels of
>  >  conformance, but this does provide a pathway.
>
>
>  We already have (at least) two key paths for "conformance": HTML
>  conformance + WCAG conformance.
>
>  Markup that follows HTML guidelines (and therefore results in the
>  desired DOM) is compliant.
>  Markup that doesn't follow the guidelines invokes the error handling
>  defined by HTML5 (which results in a usable DOM) is NOT compliant.
>
>  Compliant HTML may or may not be accessible; therefore it may or may
>  not be WCAG compliant.
>
>  On the omission of @alt ... It does not prevent the creation of a
>  usable DOM (in the way mismatched or unexpected tags or unknown syntax
>  does). It does impact accessibility. Therefore (imho) it belongs in
>  WCAG, not HTML.
>
>  I'm aware of these differing points of view:
>  - if we stamp code as 'compliant html' it doesn't raise
>  author/developer awareness of accessibility issues.
>  - if we do stamp code as 'compliant html' (due to accessibility
>  issues) then authors/developers may give up on compliance altogether.
>
>  I'm of the opinion we should give authors/developers some credit to
>  make decisions about what level of compliance checking they need to
>  undertake, and what they do with the results. (Many education/outreach
>  efforts exist to expand this, and they need to continue). In some
>  situations, I can see an author/developer wanting and/or needing to
>  assess the html compliance. Sometimes a task being undertaken is at
>  that level. Building authoring tools seems the most obvious, where
>  checking the output html is compliant is #1. Possibly they need to
>  balance this with ATAG compliance more than WCAG ...
>
>  Anyway, that's my opinion. Keep html compliance tightly focussed on
>  ensuring source markup follows the guidelines and doesn't invoke any
>  of the exception handling defined by html5 (or warn where it does so
>  the markup can be fixed). That's what I need as an author. When I want
>  to check accessibility (and I will) I will check compliance against
>  WCAG, not HTML5.
>
>  Now if you want to address the concern of raising awareness of
>  accessibility issues when checking html compliance, then build WCAG
>  compliance checking into the same tool that does html5 compliance
>  checking. Enable it by default and allow testers to disable it,
>  perhaps?
>
>  Hope this is a somewhat helpful addition to a long discussion. So much
>  talk of alt, I'm getting thoroughly tired of the attribute!
>
>  Has anyone asked ... if I use <figure> and <legend> with an <img>, do
>  I need to use @alt as well?
>  In the short term, I'd consider it essential for accessibility. But
>  longterm, when assistive technology catches up and penetrates the
>  customer base (yes I know this takes ages), I'm fully confident figure
>  + legend could be enough in many situations and @alt should be
>  optional (and I could use alt="" I know, but I'd be happy to leave it
>  out. Less typing.)
>
>  cheers
>  Ben
>

Received on Monday, 5 May 2008 03:07:08 UTC