Browser characteristics

Here's my very tardy action item on browser characteristics.  I hope it will
help in our discussion of user agent capabilities on Thursday's call.

I think WCAG 1.0 implies that all browsers support the following

Rendering of HTML 2.0 or greater
Link following via http GET
links in the http:// and mailto: formats
<img> and alt
Form submission via http GET and http POST

We've assumed that all these features are present, yet some early browsers
did not support forms or mailto.  Remember when HTML authoring guides used
to admonish authors to put an email link on all forms?  And, just in case
they also didn't support mailto,  to put a cut-and-paste-able email address
on there too?
There are no guidelines about this in WCAG 1.0, so we've obviously drawn a
line about backward compatibility.

A fair bit of time has passed since WCAG 1.0 was created, and it may be time
to move that line.  I offer for your consideration two features that are
widely supported in mainstream browsers.  I am limiting this to HTML
browsers, not WAP phones, as a believe that WAP/WML and HTML will always be
separate final-format renderings created from some single data source.

1.) 
Some form of scripting.  It would be very useful to be able to offer
techniques for making scripts directly accessible.  Yet, WCAG 1.0 says that
you shouldn't do anything in script that you can't also do in noscript tag.
This rules out a lot of useful features, so of which may even make a page
more accessible to a user with a browser and accessibility aid that support
it.  There are browsers for all major platforms (including Windows CE
handheld devices) that support these forms of scripting.
Here's one possible way to define minimal script support:
*	ECMAscript (standards-based javascript)
*	some level of Document Object Model accessible by script (maybe the
intersection of script supported by netscape 3 and the DOM level-1 spec?)
*	links in the javascript: format

2.)
tables, including nesting.  Note that this does not remove the requirement
that tables linearize well for voice rendering.  It just moves the onus to
the assistive technology instead of the author.

On a somewhat related topic, we should spend some time considering what to
do about accessibility features that have been implemented in some browsers
and not others.  For example, IE 5 has implemented tabindex, accesskey,
label,  and other accessibility features that degrade gracefully on other
browsers.  It would be nice to see some techniques that say "use this spiffy
new feature" instead of "don't use this crumby old feature".

Received on Wednesday, 29 November 2000 00:33:11 UTC