Thread Subject: Re: Action Item #2 - Definition of Web Page
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: Peter Korn
Date: Fri, Aug 24 2007 3:50 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Barrett, Don: "Re: Action Item #2 - Definition of Web Page"
- Previous message in thread: Peter Wallack: "Re: Action Item #2 - Definition of Web Page"
- Messages sorted by: Author | Thread | Date
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.
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
- Next message in Thread: Barrett, Don: "Re: Action Item #2 - Definition of Web Page"
- Previous message in Thread: Peter Wallack: "Re: Action Item #2 - Definition of Web Page"