LC-1320 NEW PROBLEM Re: Your comments on WCAG 2.0 Last Call Draft of April 2006

On Fri, 18 May 2007 01:28:47 +0200, Loretta Guarino Reid  
<lorettaguarino@google.com> wrote:

> ----------------------------------------------------------
> Comment 6:
>
> Source:  
> http://www.w3.org/mid/op.tbly4lvhwxe0ny@researchsft.myhome.westell.com
> (Issue ID: LC-1320)
>
> Technical/substantive issue?
>
> The current requirement fo unambiguous parsing is impossible to meet -
> there are always multiple ways of parsing any data.
>
> Instead I suggest the old wording of "conforms to formal published
> grammars".
>
> This makes it feasible for User Agents to recognise the content and parse
> it either according to the rules for such grammars, or in cases where it
> is necessary (such as HTML) to use specifically adapted parsing  
> techniques.
>
> cheers
>
> Chaals
>
> ----------------------------
> Response from Working Group:
> ----------------------------
>
> To make this requirement easier to understand, we have reworded SC
> 4.1.1 as follows:
>
> Content implemented using markup languages has elements with complete
> start and end tags, except as allowed by their specifications, and are
> nested according to their specifications.
>
> Note: Start and end tags that are missing a critical character in
> their formation, such as a closing angle bracket or a mismatched
> attribute value quote are not complete.
>
> The working group looked at this topic carefully over an extended
> period of time and concluded that requiring strict adherence to all
> aspects of specifications does not necessarily result in an increase
> in accessibility. For example, it is possible to create invalid pages
> that present no accessibility barriers. It is also possible in certain
> situations to enhance accessibility through the use of markup that is
> not part of the specification.
>
> The working group must work within its charter and only include things
> that directly affected accessibility. Some aspects of "use
> technologies according to specification" and validity do relate to
> accessibility. However, others do not. So requiring validity would
> take us beyond our charter. We do recommend it though and it is our #1
> technique listed for conforming to SC 4.1.1.

The current requirement could be expressed more clearly by referring to  
the XML concept of "well-formedness" (which it instead attempts to  
replicate), and analagous constructs of basic syntax in other languages.

I recognise that it is possible to write invalid documents which  
nevertheless improve accessibility. A specific example would be making use  
of the embed element in "HTML tag-soup". It is also, of course, possible  
to do this in a way which is actually valid content, by extending the DTD.  
Joe Clark recently suggested an example method for this specific case in  
XHTML [1], and there is no requirement to break validity in order to use  
such extensions. Markup languages in common use (with the single exception  
of CSS) actually incorporate specific extension mechanisms in order to  
make it possible to use these while maintaining validity

While user agents are often required, in practical usage, to support by  
reverse-engineering and guesswork a number of undocumented conventions and  
semi-documented private extensions used to extend markup languages,  
allowing authors to rely on these has the effect of making it far more  
difficult to sytematically improve user agents. Unoducmented behaviour is  
effectively irreproducible or very difficult to reproduce and thus  
difficult or impossible to support in assistive technology.

Requiring any such extension mechanism to be at least implemented  
according to the rules of the relevant markup language would have the  
effect of reducing the amount of guesswork and reverse engineering  
required of user agents, incorporating a requirement into the dependent  
Authoring Tool Accessibility Guidelines, while not outlawing the practice  
of extending languages in order to enhance accessibility, nor of using  
those extensions in content.

Indeed, requiring that the markup construct used be in accordance with  
publicly documented semantics (where publicly docmented actually applies  
to the scope of use - so for an intranet, under the structure of  
"accessibility supported" you only have to make the documentation  
available to those who are responsible for tools used within that  
environment) would enhance accessibility in general by requiring the use  
of open standards, rather than allowing for undocumented behaviour to be  
exploited.

I therefore feel that the original narrow question raised has been  
answered by the change, but that the result is still unsatisfactory and  
the issue of appropriate requirements in this area is not satisfactorily  
resolved.

cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com  Catch up: Speed Dial  http://opera.com

Received on Monday, 11 June 2007 11:06:43 UTC