Proposal for 1.3, "Ensure that information, functionality, and structure are separable from presentation"

Here is my attempt at rewriting 1.3. My tack here was to write 
success criteria that applied mostly to structured formats, like 
(X)HTML and tagged PDF, while allowing unstructured formats (JPEG, 
plain text) where necessary, since they're not going to go away and 
are not necessarily inaccessible.


	Guideline 1.3
	Where permitted by the markup languages
	and technologies in use, ensure the separation of
	structure, presentation, and behaviour.

Every markup language (e.g., HTML) or technology (PDF) has limits 
within which we must work, hence the phrase "where permitted."

If you're using something like JPEG or plain text, the guideline 
becomes inapplicable. I am not in favour of warping the guideline so 
that the only thing you could ever use would be HTML. We know in 
practice that the vast majority of Web pages will use HTML; we don't 
have to gild the lily.

	Level 1 success criteria

	1. Structures within the document can be
	programmatically determined.

This means use (X)HTML, basically. It could also mean tagged PDF. I 
have a technique in mind for plain-text documents that we could talk 
about later.

	2. Structural markup or coding is used to encode
	semantics to the extent possible for the content.

So now that you're using (X)HTML or tagged PDF, you have to use the 
correct element for whatever you're encoding (*within reason*; there 
will always be exceptional cases where authors must approximate). 
This handily takes care of the obsession with emphasis found in 
previous versions.

	3. Information presented through colour is also
	available through markup, labelling, or both.

This is still really a very small issue that only markedly affects 
people with colour deficiency. It's a remnant of the punitive 
attitude found in WCAG 1.0-- that colour shouldn't be used (because, 
I guess, that would be "pretty" and pretty ain't accessible; there 
was also a near-total ignorance of the true facts of colour 
deficiency). I'm leaving it in because it can't hurt, and redundant 
coding practices are nonetheless preferred.

You can use <strong> or some other markup *or* you could use words, 
pictures, movies, or some other kind of label or both. Note how this 
collapses the former Level 1 and 2 success criteria, whose 
differences were picayune at best. It doesn't really matter if the 
error page on your form uses <strong> or a line of text pointing you 
to the field you forgot to fill in. (At any rate, that doesn't solve 
the true accessibility problem of that case.)

	4. Markup or coding for presentation or behaviour uses
	accessibility features available in the technologies
	being used.

If there's an accessibility feature available, use it (e.g., backup 
font families in CSS, generic handlers in JavaScript). I think this 
should be explicitly mentioned, rather than simply implied in 4.2, 
"Ensure that user interfaces are accessible or provide an accessible 
alternative(s)."

In the case of Flash, your file may not have structure or anything 
like it, so the foregoing criteria would not apply. But Flash 
nonetheless has accessibility features, which you must use according 
to this criterion.

	Level 2 success criterion

	Only markup languages and technologies that enable
	separation of structure, presentation, and behaviour are
	used.

This one's iffy. It would essentially ban plain text and any 
unstructured format. On its face, it bans every graphic format (save 
for SVG) when used without an HTML or similar wrapper and the 
expected text equivalents. If you think that's an uncommon scenario, 
check what happens when you click a thumbnail on a photo page that 
loads the full-sized version. Even I do that and I hardly find it 
inaccessible.


WHY ISN'T "INFORMATION" IN THERE?
Because we don't need it. It's tautological and unnecessary for the 
competent Web developer.

Further, the Introduction to our guidelines lays it out already: 
"This document outlines design principles for creating accessible Web 
content." We are writing the Web *Content* Accessibility Guidelines. 
Content is information.

<http://www.w3.org/TR/WCAG20/#intro>

-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
     Expect criticism if you top-post

Received on Tuesday, 26 April 2005 16:06:10 UTC