Re: Trying to better explain concern about mapping technology-specifics to success criteria

>In other words, it seems that some HTML structural elements are more 
>important to accessibility than others, but the minimum level 
>success criteria put them all at the same importance.

	I would say that few HTML *elements* are specifically 
important to accessibility. <object> is one. What's really important 
are *attributes*, some of which are perennially ignored (like title 
on everything), others required (like alt on <area> and <img>).

>The minimum level success criteria for checkpoint 1.3 are:
>
>1. any information that is conveyed through presentation formatting 
>is also provided in either text or structure.

	Maybe someone could explain what that bit means.

	Aren't we really trying to say "Don't use HTML incorrectly"? 
(That's another guideline already, isn't it?) In other words, an 
ill-informed developer might use

		<p><big><bold><font color="red">

to make a paragraph *look* like a header to a sighted person, but the 
structure of the <h1> through <h6> tags is lost.

	A plain reading of the requirement above would force someone 
who wanted to use <p><big><bold><font color="red"> to *also* surround 
all that in heading tags.

	I think not.

>These seem to fall into 2 categories:
>
>1. those elements that genuinely provide structure, are commonly 
>used, and make a much larger accessibility impact when they are 
>used. e.g. H1-H6, UL, OL LI, TH, LABEL, etc.

i.e., are well-supported by current browsers and adaptive technology, 
which falsely leads us to believe they are more important.

>2. those elements that are not commonly used or supported and do not 
>provide a large accessibility benefit. e.g. CITE, VAR, KBD, etc.

i.e., are poorly-supported by current browsers and adaptive 
technology, which falsely leads us to believe they are less 
important. (And I dispute that <cite>, <var>, and <kbd> are 
poorly-supported. If anything is poorly supported, <object> is.)

	Browser and (for example) screen-reader makers are both 
guilty here. Try finding a browser that supports *all*, absolutely 
all, of HTML 4, a specification dating back to 1999. (summary on 
<table>, anyone? cite on <blockquote>, perhaps?) Even getting 
something as simple as longdesc support out of these people is like 
pulling teeth. (iCab, Moz, and NN6 have it. IE doesn't.)

	Now try to find a screen reader that understands *all*, and I 
do mean all, of the accessibility elements and attributes available 
in HTML. (How about longdesc on <iframe>? How about nested <object>? 
How about title on everything, and yes, *title is an accessibility 
feature*, as I have tried to explain before?)

	<http://lists.w3.org/Archives/Public/w3c-wai-gl/2001OctDec/0463.html>

	"Not commonly used" is irrelevant. If it's in the spec, it 
must be supported. "Not commonly... supported"? At least you're being 
honest. You're saying, in effect, "Jaws for Windows can't handle it, 
so let's pretend it doesn't matter." (That's merely to draw one 
example.)


>They don't provide a sizable benefit because if you don't know that 
>something is a citation by the markup

	This is self-contradictory. If you mark it up with 
<cite></cite>, it is up to your browser or adaptive technology to 
*tell* you it's a citation! If an author marks up a citation 
correctly, he or she has done the job. Responsibility then falls to 
the browser or device.

>hopefully you can glean that from the context. Unlike headings which 
>can be used as navigation markers as well as create the structure 
>that the document is built on.

	Here you are specifically referring to an *interface* 
currently used in screen readers (and one browser-- iCab will list a 
page's headers for you). You are allowing this currently-used 
interface to influence your conception of what's important in HTML 
markup. All HTML markup is important. Some of it may be more 
*useful*, but that's a different question.

	Following this line of thinking, HTML elements that, say, 
Jaws for Windows can't list in a handy-dandy group should all be 
eliminated. The thinking here seems to be "Wow. Jaws lets a blind 
person navigate from heading to heading. That's just so terribly 
clever. Why didn't I think of that? I feel slightly embarrassed that 
I didn't. So headings must be really important then! And who uses 
<var> anyway?"

	Let me add that this habit of being influenced by current 
adaptive technology (invariably meaning a screen reader, invariably 
meaning Jaws for Windows) leads to absurd advice that gets 
accessibility advocates laughed out of the room. Example: Claiming 
that all text between <a> and </a> tags must be self-explanatory on 
the off chance that someone is perusing the document link by link. 
That's not how hypertext works; <a> is an inline element and can and 
should be used smack dab in the middle of a sentence if that's what 
you want to do. I see a call for people to "glean that from context" 
in the discussion of <cite> above; why is that desirable here but not 
in the case of freeform link text? But I digress.

>Does this make more sense now? Can you see how a sub-priority scheme 
>is almost forming from this? Or do you think they are all equally 
>important?

	No. No. Yes.

>  This might be an incorrect premise on my part (that some are less 
>important to accessibility than others).

	Some HTML elements are treated more *conspicuously* by 
certain *present-day devices*, leading to the misapprehension that 
they really are indisputably more important and everything else can 
be eliminated. This kind of Oprah effect-- "Oprah mentioned the <h6> 
tag on her show today! We really ought to treat it special!"-- is to 
be discouraged.

	I am not really wild about fashioning the WCAG around the 
deficiencies of current adaptive technology. We're already stuck with 
requirements like this one--

>><http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html#tech-divide-links>
>>
>>Until user agents (including assistive technologies) render 
>>adjacent links distinctly, include non-link, printable characters 
>>(surrounded by spaces) between adjacent links.

	Adjacent links are *always* discernible in valid HTML. Example:

	<a>Parsley</a><a>Sage</a><a>Rosemary</a><a>Thyme</a>

	is quite clearly four separate links. If your adaptive 
technology can't keep them straight (or your visual browser uses an 
unbroken underline for all four, making you think they're a single 
unit), that's not our problem. We shouldn't be saddled with a 
requirement to *work around* errors in adaptive technology 
essentially forever. (Pedants always conveniently omit the "until 
user agents" part, and in any event it causes developers to be guilty 
until proven innocent: "Unless you can prove that adaptive technology 
no longer needs this addition, I am going to accuse you of 
negligently designing an inaccessible site." This *is* in fact the 
tone often used with developers. High dudgeon can be called for, but 
certainly not in this case-- the *requirement* is broken!)

	Let's break out of the habit of accommodating the 
peccadilloes of software makers who cannot be bothered to support all 
of HTML. And I do mean *all*. Nor should we be influenced by the way 
current software does things.

	To paraphrase Just van Rossum and Erik van Blokland of 
LettError, let's not allow our IdeaSpace to be limited to the 
available ToolSpace 
<http://www.fawny.org/typoexpoagogo.html#toolspace>.

>"Is this an isolated instance or is it part of a more general problem?"

	The latter.
-- 

     Joe Clark | joeclark@joeclark.org
     Accessibility <http://joeclark.org/access/>
     Weblogs and articles <http://joeclark.org/weblogs/>
     <http://joeclark.org/writing/> | <http://fawny.org/>

Received on Sunday, 14 July 2002 19:12:24 UTC