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

** Comments marked **GV below

	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.


**GV:   Good points.   Does this give a blank check though to technologies
that could but don't bother to allow this - so information in presentation
is lost? 
 


	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.

** GV:  If there is to be a limitation - it must be reflected in SCs or JPEG
will be covered. 




	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.


** GV:  To the extent possible needs to be made objective.




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


** GV:  very good wording.




	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.


** GV: this looks like part of the 4.2 discussion.  What if there is no
accessibility features available.  Can I use the technology and just not
have it accessible? 





	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.


** GV:   Ah here it is.   Hmmmm. I don't think we should do this.  but we
should require alternate presentation if it is not possible with the
technology talked about.    

Then it wouldn't ban anything.  

Plain text though is a question. Is it structure we are trying to preserve
or is it information we are trying to not lose?  That is the discussion
point.    






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 Thursday, 28 April 2005 20:02:13 UTC