Re: Bare-bones proposal for 1.3, "Ensure that information, functionality, and structure are separable from presentation" (re-send)

On Fri, May 13, 2005 at 03:54:55PM +0000, Joe Clark wrote:
> 
> >In so far as it requires structure to be programmatically determinable, 
> >and technologies (including of course markup languages) to be used 
> >according to specification, it is redundant due to guideline 1.3 sc1 and 
> >guideline 4.1 respectively.
> 
> The redundancy is in dispute. The harm of being redundant is arguably 
> lower than the harm of leaving it out.

So where's the argument then?


> 
> >Requiring that "semantics" be encoded as far as possible for the content 
> >is extremely onerous. It would demand among other things that a 
> >symbolic, formal language be used to express the content instead of a 
> >natural language wherever feasible, which is hardly warranted at level 
> >1.
> 
> False. See below. You're simply misunderstanding the sense of the term 
> "semantics."

No, I am not misunderstanding the sense of the term at all. Following 
the passage quoted above, I set out an argument to demonstrate how the 
term "semantics" as applied to Web standards (including markup 
languages) has the same sense as applied to natural languages. 


> 
> >Nor should WCAG seek to narrow or redefine the meaning of the term
> >"semantics,"
> 
> While the WCAG Working Group was doing other things, leaders and pioneers 
> in the field of Web standards added a sense to that term. I am aware that 
> many Working Group members find it odd to discuss "document semantics" in 
> this context, but everyone involved in Web standards finds it no big deal. 
> Whether you are aware of it or not, you *are* working in the field of Web 
> standards and, as I have explained before, if you want people to work at 
> your level you have to work at theirs.

For the record, I am familiar with developments in Web standards that 
have taken place in the W3C, Oasis and other fora. Doubtless other 
members of the working group are likewise well aware of these. None of 
this work has however changed the concept of "semantics" or "document 
semantics", as I explained in my original post. Any adoption of a narrow 
definition or concept of the term by WCAG would create or perpetuate 
misunderstandings in this regard.

> 
> In short, the world has changed and WCAG WG needs to adapt.

Some people may hold a narrow view of what "document semantics" are, but 
in so far as they do it is founded on a misconception of how the 
semantics of a markup language differ from those of, for example, a 
natural language. Furthermore, WCAG will be read by many people who do 
not subscribe to such a narrow definition, whereas they have a perfectly 
clear understanding of what "semantics" are in the customarily accepted 
sense of the term.

> 
> >>	3. Information presented through colour is also
> >>	available through markup, labelling, or both.
> >
> >This wording assumes that a markup language is being used, which is not
> >always the case. For example, tagged PDF is not a markup language;
> 
> In a strict sense, *possibly*. Nonetheless, it adds structure.

It can't be because it doesn't have a syntax. You can't define a 
formal generative grammar for a PDF document, so far as I know. To be a 
markup language it needs to have a syntax with associated semantics and 
I don't think it meets those criteria. Even if we use a looser 
definition of "markup language", it is still stretching the concept 
beyond what most people working in markup languages would consider a 
paradigm case. It would have to be defined accordingly, and I don't 
think WCAG should be entering upon the task of defining what a markup 
language is.


> 
> ><propose>
> >Information presented through colour can also be programmatically
> >identified.
> ></propose>
> 
> I think that's as clear as mud and is about as helpful as the oldschool 
> WCAG WG guidelines. My wording is actually understandable and does not 
> fail to achieve technological neutrality, as impled.
> 

To the contrary, the proposal is understandable in that it uses 
terminology which is consistent with the remainder of WCAG 2.0. Whoever 
grasps a few key concepts (such as programmatic determination and 
identification) is thereby equipped with an understanding of all the 
contexts in which these terms appear throughout the document. The 
pay-off, in short, is significant, without sacrificing generality. The 
alternative proposal, however, is limited to markup languages and is 
therefore inadequate as it stands as it doesn't apply to formats other 
than markup languages. To reiterate an earlier point, WCAG should not 
attempt to define "markup language" to include everything that can 
encode structure.
> >>	4. Markup or coding for presentation or behaviour uses
> >>	accessibility features available in the technologies
> >>	being used.
> >
> >The main problem with this is that it fails to identify what the
> >"accessibility features" are.
> 
> That's why we have techniques. You realize we do this already for 
> WCAG 1.0, I trust?

The techniques however are non-normative. Consequently they can't define 
what the "accessibility" features of a technology are in a way that is 
authoritative for the application of the success criteria. If a 
technical specification, which is normative, identifies certain 
components as "accessibility features" then it is possible to use that 
concept in the guidelines; but not all specifications do, and as such, 
without a normative definition of "accessibility feature" we are left 
with a vague proposal which shouldn't be included in WCAG.
> 
> >Suppose the technology does not have an authoritative specification,
> 
> Three examples, please?

I create three markup languages and provide client-side support for them 
(Javascript, style sheets, etc.), and I then use them to construct my 
Web content.

The more general point is that WCAG is being written not only to cover 
existing technologies, but also foreseeable and anticipated future 
developments. This is what it means to write a specification that is 
designed to be as stable as possible over time. Thus, one shouldn't 
introduce a definition or requirement into the document when one is 
aware that, using currently available technology, or realistically 
anticipated technology, one can construct counter-examples that give 
rise to problems with the requirement.
> 
> >Worse, I can't think of a good example in which this wouldn't be 
> >redundant with the remainder of 1.3,
> 
> Well, how 'bout the fact that e.g. tabindex and accesskey are strictly 
> optional attributes *according to spec* and are also *not semantic*?
> 
> Leave this one out and there is no requirement whatsoever to use those, 
> for example.

If you want to cover these, then guideline 1.3 is not the appropriate 
context. Both features facilitate keyboard operation and navigation, so 
they should be covered somewhere under guideline 2. If this isn't 
already required at some level either in the current wording or any of 
the guideline 2.x proposals it should be generalized and suitably 
included.

> 
> As I explained twice already, that success criterion was added to cover 
> unstructured document formats like Flash that nonetheless have 
> accessibility features. Can't use structure? OK, we'll live with that. But 
> you *must* design for accessibility.
> 

The proper way to deal with this is not to introduce a vague term such 
as "accessibility features", but to cover the required implementation 
under relevant success criteria throughout the guidelines.

I could live with a success criterion that said, in effect, "where a 
technology is defined by a formal specification that defines certain 
features as enhancing accessibility, those features are used", but the 
main criticism of this would be that it isn't clear at what level it 
belongs. The features in question could be very important or relatively 
unimportant depending on the technology and its specification.

> >This whole proposal is untestable:
> 
> It's perfectly testable. You run the page through the validator. You then 
> use human testing to examine the source code (in [X]HTML) or tags (in 
> PDF), to give two examples. If every single object on the page is a div or 
> a span, you flunk the criterion. If you're using headings, paragraphs, 
> lists, and the like, according to the *document semantics*, you pass.

That's all covered by level 1 sc1 and guideline 4.1, reinforcing my 
argument that there is nothing extra for this proposed level 2 success 
criterion to accomplish.

> >If structure and behaviour-relevant details such as role and state can 
> >be programmatically determined, surely taht should suffice and there is 
> >nothing extra to be accomplished here that helps accessibility.
> 
> Oh?
> 
> What if I mark up everything in my document as a paragraph? How does that 
> not harm accessibility?

Doing this would fail 1.3 level 1 sc 1 unless the structure of the 
document consists only of a series of paragraphs. The success criterion 
requires the structure to be programmaticaly determinable, and what the 
structure is depends on the nature of the content, and not on how the 
author chooses on a whim to misrepresent it in a markup language. It 
follows that the above scenario is precluded at level 1.

> 
> I am aware that Web standards are unfamiliar to many W> 
orking Group 
> members, despite the fact they are actually writing a standard, but I 
> would request doing a bit of homework before dismissing established 
> concepts like these.

This is an ad hominem argument and should be dismissed as such.

Received on Saturday, 14 May 2005 06:21:20 UTC