Thread Subject: Re: Action Item #2 - Definition of Web Page

Note

This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.

From: David Poehlman
Date: Mon, Aug 27 2007 4:10 AM

Our concern is not to "squeeze" out the web but to acknowledge possibly
before the fact is realized that the resources are blending.

----- Original Message -----
From: "Barrett, Don" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Sunday, August 26, 2007 11:31 PM
Subject: Re: [teitac-websoftware] Action Item #2 - Definition of Web Page


Beautifully said, Peter. I concur 100%; it's time we stopped trying to
squeeze the web out of 508, covering it by inference alone. Making
reference to web content in the 508 standards serves to clarify its
coverage, rather than limit it. As someone who is all to familiar with
the transient lot of the uninitiated 508 Coordinator in the Federal
arena, I can't stress enough the critical importance of specificity
where possible in helping readers to understand the standards. To go
from having 1194.22 as a separate set of standards relating to the web
to no standards which specifically refer to web coverage, relying
instead upon the knowledge of vendors and Federal personnel to "know"
when web coverage is implied is, I believe, a grave error in judgment.
As long as we construct standards which are inclusive of all
technologies and are thus additive by their specificity, I believe we
will be doing a great service to those down the road who will be looking
to the standards for guidance as to their applicability.

Don




-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Korn
Sent: Friday, August 24, 2007 5:46 PM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Action Item #2 - Definition of Web
Page

Hi Peter,

At the end of your comment, you wrote:

" By making those changes, we still accomplish my goal: no reference to
a 'web page' in the entire document."

I fail to see the value of that goal. At least, if we re-state the
reference to "HTML document", then I definitely fail to see the value.
Just as there are unique things in video content (for which we note
specific provisions), there are unique things to web content and web
documents. And unlike video content, we have an entire standards body
focused on understanding web document accessibility issues and
promulgating standards for web document accessibility. I believe we
loose significant value in so generalizing our standards that we cannot
clearly and unambiguously harmonize with those web standards. I am
personally not convinced that what we gain is of equal value.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.


> 3-H (Consistent identification): I don't object vehemently to
> supporting it and extending it to all products because any good UI
> design would incorporate consistent use of objects and images anyway.
> Failing to do that would make the product equally unusable by all. I
> could not possibly make an argument to a PwD that my 'software'
> identifies things differently all over the place, but that is somehow
> a good thing. Based on current debates, it still seems like less work
> for me to extend the scope than to define 'web page'.
>
> As for 3-L (Repeated blocks), I could not possibly agree more that a
> better provision would be to require structure. I'll second your vote
> to jettison this one, though it doesn't help with our harmonization
> story. But if we keep it, I still have no problem applying it to
> everything. Most software would not have repeated blocks, so it
> wouldn't apply; in the rare case it does, I still think it is
> perfectly reasonable to require such a navigation mechanism. For the
> most part the provision becomes self-scoping to web pages, without us
> having to spell it out.
>
> That leaves our good friend 3-M (Link Purpose). I abhor the thought of

> constraining a provision to what is 'currently possible', but I
> certainly don't want to open another can of worms by touching the
> other provisions. So how about this as a way to at least eliminate the

> 'web page' term:
>
> It must be possible to determine the purpose of each link from the
> link text or, when the content format supports it, the link text
> together with its programmatically determined link context.
>
>
> By making those changes, we still accomplish my goal: no reference to
> a 'web page' in the entire document.
> Peter Wallack
> Accessibility Program Director
> Oracle Corporation

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University