Re: Murky ratings

If an author today were to perfectly follow the current
incarnation of the WAI guidelines and make a web page
theoretically accessible, would that page necessarily be practically
accessible to anyone today? Moreover, how could we
determine if it would be accessible to someone in the future?
And at what date in the future? (consider CSS absolute positioning) 
Do we have any guarantee that future combinations of assistive 
technology and the browsers with which they work will 
actually support these authored features in a single 
uniform way that conveys the extra information for 
accessibility? If not, there will need
to be additional guidelines that provide alternative
strategies to make pages accessible. The simple AREA ALT
tag example in my original posting illustrates just this
problem (and it gets much worse, just try doing such
an analysis for each guideline). It is problematic
to imagine that at some point we will achieve a fixed standard
for authoring, independent of browsers and assistive technology,
which, if met, defines the true/false accessibility of a page.
This is clear to me from the many feedback letters 
Bobby gets where people write, "I did X,Y,Z which are in the
guidelines and it says my page is accessible, but such and such
a person can't access this information." Or the reverse, I did
X,Y,Z and a person who is blind says my page is accessible,
but your program says its not." In the heterogeneous world
of the web, will this ever change?

Each guideline already has implicitly defined a set of browsers and 
assistive technology for which it refers. We can choose
to ignore this implicit assignment and claim that we are
establishing a standard for accessibility but we ultimately
shoot ourselves in the foot.

All I am arguing for is storing MORE information with each 
guideline (not less). But information which provides a very
exacting notion of accessibility and anchors this notion to
moments in time as a function of the technology that people
use. This extra information could then be used by a program to 
CREATE a set of guidelines of which the current WAI working
guidelines would be one instance.

I like Nir's comment below that a theoretical browser construct
would also be useful. In such a procedure a guideline might
be marked with being relevant for HTML 4.0 (an imaginary
browser that perfectly conforms to the HTML 4.0 spec) and, when
real browsers and assistive technology combinations exist
that support this feature they are added to the extra
data in the guideline. For example:

Guideline: Use CSS for all absolute position
Solution: ... Description of how to do this ...
Population Affected: Non-sighted
Guideline Relevant For: HTML 4.0
Assistive Technology Relevant For: None

Guideline Relevant For: IE 5.0
Assistive Technology Relevant For: Jaws 4.0

I think it's important NOT to overly separate our notions of
future (and sometimes theoretical) accessibility from 
present accessibility. After all, there will always be
many people using many different technologies.

Josh Krieger
CAST

nir dagan wrote:
> 
> I disagree with the approach that the guidelines should
> be based on for what browser something works or not.
> For the guidelines to be stable they should be based on specs.
> 
> Collecting this data about browsers may be useful
> for _users_ to decide what browser to use. Authors should
> not be bothered with features of particular browsers.
> 
> I think that the guidelines already take current
> (in a few months obsolete) browsers features/bugs
> too much (e.g., "avoid word wrapping..." how can you do that?
> this dependes on font size and resolution of the monitor.)
> 
> It is much more _practical_ to specify in what
> _theoretical_ browsers it works:
> 
> Example:
> Use alt in AREA : HTML 3.2 and 4.0 conforming browsers.
> Population affected: sighted users with images turned
> off, among others.
> 
> Note: HTML 2.0 does not support the AREA element thus an
> HTML2.0 browser wouldn't create a link at all.
> Population affected: all users of HTML2.0 browsers.
> 
> Concerning institutions that have guidelines like "HTML3.2 and Bobby
> Approved", I say: if a page is not consistent with the guidelines
> as it fails to implement an HTML4.0 feature (say, summary in TABLE),
> it should be upgraded to HTML4.0. Practically, any valid HTML3.2
> document is also a valid HTML4.0 transitional one. One doesn't
> have to rewrite the whole page, just to add the new feature.
> 
> Institutions should set guidelines like "current W3C
> recommendation" (current with respect to document's creation date,
> not the guidelines date) rather than HTMLy.x . The approval of
> Bobby should also be dependent on Bobby's criteria on the
> creation date of the document. This way no inconsistencies
> can occur.
> 
> Regards,
> Nir Dagan
> http://www.econ.upf.es/%7Edagan/

Received on Thursday, 14 May 1998 09:40:34 UTC