RE: [4.1] Overview and summary of guideline 4.1

> -----Original Message-----
> From: w3c-wai-gl-request@w3.org 
> [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Joe Clark
> Sent: woensdag 21 januari 2004 0:49
> To: WAI-GL
> Subject: Re: [4.1] Overview and summary of guideline 4.1
> 
> 
> Excellent summary!

Thank you!

> >Greg Gay wonders whether 4.1 includes non-W3C technologies 
> as well. [snip]
> 
> and:
> 
> >In addition to the previous issue, Greg Gay emphasizes that in real 
> >world situations, developers need to be able to use workarounds that 
> >violate guidelines, provided they are necessary and they are 
> documented 
> >in an accessibility statement. He gives some examples (use of 
> >target-attribute to spawn new windows, lack of support for 
> font size in 
> >EM in Netscape 4) to illustrate this necessity.
> 
> Those are weak examples at best, indicative of poor authoring 
> experience. (Why not just @import a different CSS file to 
> fool Netscape 4?)

Yep, I agree with you there. Someone with decent HTML writing skills will
probably know what hoops to jump through to achieve cross-browser
compatibility. Too bad hoop jumping is sometimes necessary, but that's a UA
issue, not an accessibility issue.

[snip "embed" is better example]

> There are options, though.
> 
> * The best one is to custom-hack your DOCTYPE. It's XHTML, 
> which is XML, which is eXtensible. Want to use <embed>? Write 
> a DOCTYPE that makes it legal. (Same goes for other banned 
> elements and attributes. 
> I wish K10K would do this to get rid of their tiny 
> invalidities, for example.

Being a computer scientist, I like this solution. However, I don't think
it's very practical for the majority of people creating web content. The
Dutch accessibility initiative is called "no more thresholds", I guess this
should apply to the level of technical knowledge required to build
accessible websites as well :-)

Valid code isn't the holy grail, I think. If you rewrite the specs to
include new tags, how are user agents supposed to know how to render them? I
can create my own XHTML pages with an adapted DTD (for example to include
the <sarcastic> tag for sarcastic remarks) and write web content that is
valid against this DTD. Since no user agent know how to treat the
<sarcastic> tag, it's utterly useless and doesn't help accessibility at all.
Just following specifications isn't everything, the specifications
themselves should be (if possible) open standards or at least publically
available and well documented (in my opinion).

> 
> <http://K10K.net>
> 
> <http://validator.w3.org:8001/check?uri=http://k10k.net/&chars
> et=(detect+automatically)&verbose=1&fussy=1>.
> 
> * You can also faux-write the <embed> element using 
> JavaScript. The designer of OneTrueFit.com, a very nice 
> compliant site, did that.
> 
> <http://www.webstandards.org/learn/interviews/rcarver/#q9>
> <http://www.fivesevensix.com/studies/onetruefit/>

True, but then Javascript becomes a prerequisite for Java. I don't think we
should make different technologies co-dependant. Some people I know have
disabled Javascript (to prevent annoying popups etc) but have Java enabled.
With this solution, they would not be able to use the Java applet.

> 
> >Is validity an accessibility issue?
> >
> >The need to use technologies according to specification is a broader 
> >issue than most of the guidelines in WCAG. In issue 572 as 
> well as on 
> >the mailinglist, people have wondered whether this guideline 
> should be 
> >in WCAG because they feel it's not about accessibility.
> >Others have argued that valid markup increases the chances 
> of correct 
> >rendering of the content which directly benefits accessibility.
> 
> Correct. Looking for prior art?
> 
> <http://joeclark.org/book/sashay/serialization/Chapter05.html>

"none of us should be made to suffer for the longtime failure of browser
makers to conform to W3C standards". I like that :-) 

You can take this too far, however. I recently encountered a web developer
who built a page according to W3C standards, but it didn't work in Internet
Explorer (>90% browser in the Netherlands). He argued the same point, that
is was not his problem the browser failed to conform to the standards.
Needless to say, the client didn't see it that way. 

In my opinion, following standards is a necessary but not sufficient
prerequisite for creating web content. You should still check if the
resulting HTML works in current browsers. 
> 
> >  Applicability to non-W3C technologies
> >
> >...Do we allow the use of proprietary technologies?
> 
> WAI needs to resolve that issue quickly, if only because PDF 
> and Flash are two non-W3C formats with accessibility built 
> in. (There are lots of those. DVD, for example.) WAI has 
> flirted with these dangerous and alien technologies before in 
> its guidelines:
> 
> <http://www.w3.org/WAI/GL/WCAG-PDF-TECHS-20010913/Overview.html>
> PDF Techniques for Web Content Accessibility Guidelines 1.0 and 2.0
> 
> I know that document is orphaned, but it's important for WAI 
> to decide if it's going to publish accessibility guidelines 
> for other formats. *I* think it should.

I think there is another reason to allow non-W3C technologies: to make WCAG
2 more flexible for the future. We don't know what great assistive plugins
will be invented in the next 5 years that can greatly benefit accessibility.
Do we want to exclude them beforehand? I do believe we should require an
alternative for any content that depends on non-W3C technologies, just like
we do in WCAG 1 ("Guideline 6. Ensure that pages featuring new technologies
transform gracefully.").


> 
> >Improve description of benefits of the guideline
> >
> >With an improved descriptions of the benefits, it should be 
> possible to 
> >make it clear that following this guideline helps the 
> accessibility of 
> >web content, and that this guideline is an accessibility issue.
> >
> >The current version of 4.1 includes a description of the benefit of
> >4.1 which says that it the benefits of following specifications are 
> >primarily that assistive technologies and user agents can render the 
> >content according to spec. This is not the only reason. If 
> the author 
> >does not follow markup specifications, it is left up to the 
> user agent 
> >to interpret this pseudo-markup. Since authors usually only 
> test their 
> >content in a few frequently used user agents, there is no way to 
> >predict how other user agents (such as speech synthesizers or text 
> >browsers) will interpret this data.
> 
> The problem here is how few Web pages there are in existence 
> that explain the need for valid code. I know of *one*:
> 
> <http://www.pantos.org/atw/h-valid.html>
> 

I have found a few others:
<http://valet.htmlhelp.com/page/why.html>
<http://oumph.free.fr/valid/>
<http://homepages.picknowl.com.au/tim_seifert/information/valid.html>
<http://www.htmlhelp.org/tools/validator/reasons.html>

I'm not very fond of either of them, but perhaps they can help formulate a
better explanation.

> 
> >Add example with backward compatibility
> >
> >Since backward compatibility questions keep popping up, it would be 
> >wise to include an example of how and when to allow for backward 
> >compatibility.
> 
> I don't understand this whole concept. For a lark, I 
> downloaded Netscape 1.1N on my Girl Power iMac here and tried 
> a few XHTML pages. 
> The program seems to be too old to understand virtual domain 
> hosting, so even my own page called up my host, not me. But I 
> got a couple of the Usual Suspects to load fine-- Zeldman, 
> Mezzoblue, Alazanto, Webstandards.org. It crashed on Eric 
> Meyer, oddly.

I tried Mosaic 1 on several websites. Can you imagine what headaches we're
giving the people who check the logs of the websites we visited to determine
what user agents are used to visit their websites? ;-)

> 
> Now, how far back do we have to go for "backward" compatibility? 
> Isn't this entire concept "backward"?

Webstandards.org terminated their browser upgrade campaign, because use of
standards supporting browsers have increased so much.
<http://webstandards.org/act/campaign/buc/> That suggests to me the backward
compatibility discussion will become deprecated itself in the years to come.

> 
> Aren't the people advocating invalid code for backward 
> compatibility themselves simply out of date? Why aren't they 
> familiar with the existing standards-compliant methods? 
> (@import, for heaven's sake, has been around for a couple of years.)

If I understand you correctly you don't mind providing facilities for
backward compatibility as long as it doesn't compromize the validity of the
code (for example exploiting the @import bug in NS4). That's an interesting
point, too bad about the <embed> problems or it would solve this issue. 

> 
> >Re-include requirement to follow specifications for 
> non-markup content
> >
> >[...] What shall we require about non-markup content such as Java 
> >applets, Javascripts etc.?
> 
> There *is* a standard for JavaScript, called ECMAScript.
> <http://www.ecma-international.org/publications/files/ecma-st/
> Ecma-262.pdf>
> (Google it for text version)
> 
> Now, it seems only Zeldman writes according to the ECMAScript 
> spec, but in principle it exists.

Amazing! Do you have any idea how well user agents support ECMAscript? As I
stated before, it's no use writing web content according to specs if no user
agents support the specs. 

> 
> >Since no open standards exist for these technologies,
> 
> I dispute that characterization. Do you mean "published"? 

No, I mean "open standards" as defined for example
<http://perens.com/OpenStandards/Definition.html>. Key elements of an open
standard include public availability, open to contributions by the public,
not owned by a commercial company. 

> The 
> PDF file format is published. It's so well published that OS 
> X supports it natively. IIRC the Flash file format is 
> published, but don't quote me on that. And "open"? Even the 
> development of WCAG 2, while *public*, is not something I 
> would consider "open."

Since PDF and Flash are proprietary formats, I do not think they meet the
definition for open standards. According to me, the W3C specs, including the
WCAG, are open standards, but I can see where you're coming from (that's a
whole different discussion).

> 
> >Accessibility features
> >
> >The requirement to use accessibility features if present has some 
> >relation with all the guidelines of the 'Operable' principle. If an 
> >author does not use the accessibility features, the content 
> may become 
> >less operable.
> 
> Except some of the canonical accessibility features are 
> either ill-supported or unsupported. tabindex, accesskey, 
> longdesc-- they're essentially vapourware. So does WCAG WG 
> propose to flunk authors because they leave those out?

Perhaps we should move "accessibility features are used" to level 3. It does
meet the internal criteria for a level 1 SC (does not specify how
information is used, is reasonably applicable to all websites, is reliably
testable) but requires a lot of effort from the author. These were priority
3 in WCAG 1, is we make them level 1 now it requires a lot of extra work to
upgrade a WCAG 1/level A website to WCAG 2/level 1.

> 
> We would need an exhaustive list of such "features," 
> something much better than the current 
> <http://www.w3.org/WAI/References/HTML4-access>. 

Do I hear a volunteer? ;-) 

> Then we 
> could have a rational discussion about requiring them. Few 
> accessibility features are truly required-- alt text is a 
> prime example of one that is. (You must have it to meet 
> Priority 1 and 2, for different reasons.)

Many of these features are already included in the HTML techniques document:

<http://www.w3.org/TR/2003/WD-WCAG20-HTML-TECHS-20031209/> I think that the
techniques subgroup is the best group for this discussion. I do agree with
you that we have to look at specific specifications (like HTML) to see if we
can require every author to use all of the accessibility features there. For
HTML, I think this is asking a LOT.

> 
> 
> >Using structural elements for presentation
> >
> >Using structural elements for presentation is not allowed by 
> guideline 
> >4.1 because that's not using the elements according to specification.
> 
> This is a fine line sometimes with new authors. Remember the 
> distinction between valid and semantic?
> 
> <div>Today's headline</div>
> 
> <span>By Joe Clark</span>
> 
> <span>Today's news article</span>
> 
> is valid HTML, but not semantic HTML. Do we want "according 
> to specification" to explicitly mean "do whatever you want as 
> long as it validates," or do we want the vastly superior "Use 
> elements and attributes according to their purposes as listed 
> in the relevant specifications, and validate your pages"? You 
> know which one I vote for.

I couldn't agree more. Whichever we eventually decide on for the WCAG 2, the
wording of the checkpoint should make it absolutely clear what we mean.

> 
> (Sometimes there are ambiguities and you have to do your best. 
> Simplebits discussions are full of these ambiguities. I trust 
> you all read Simplebits, and the other sites I've mentioned.)

I didn't know this site, but it looks interesting. I've added it to my
syndicated news reader. I would appreciate any other links such as this one.
I know I'm just a newbie in the area of accessibility compared to most
people on the list but I'm always willing to learn more! 

Yvette Hoitink
CEO Heritas, Enschede, The Netherlands
E-mail: y.p.hoitink@heritas.nl

Received on Wednesday, 21 January 2004 12:26:15 UTC