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

> 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.

> 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."

> 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.

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

> We should not be attempting to narrow or redefine the term.

You wouldn't be. It's already happened.

>> 	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.

> <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.

>> 	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?

> Suppose the technology does not have an authoritative specification,

Three examples, please?

> 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.

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.

> 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.

I could put ten of my standardista friends together and the required 8 or 
8.5 of them would agree on the assessment of any given page.

In fact, we can try that. Somebody give me three real-world pages to 
test-- pages unrelated to anyone in the W3C. I'll get my friends to 
evaluate them and I'll post to the list. Then you'll have actual data.

> 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?

I am aware that Web standards are unfamiliar to many Working 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.

-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
       --This.
       --What's wrong with top-posting?

Received on Friday, 13 May 2005 15:55:09 UTC