- From: Joe Clark <joeclark@joeclark.org>
- Date: Sun, 14 Jul 2002 19:11:32 -0400
- To: WAI-GL <w3c-wai-gl@w3.org>
>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