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: Peter Wallack
Date: Fri, Aug 24 2007 2:20 PM

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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'. <br>
<br>
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.<br>
<br>
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:<br>
<blockquote>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.<br>
</blockquote>
<br>
By making those changes, we still accomplish my goal: no reference to a
'web page' in the entire document.<br>
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
<br>
<br>
Peter Korn wrote:
<blockquote cite="mid: = EMAIL ADDRESS REMOVED = " type="cite">
<pre wrap="">Hi (other) Peter,

We discussed 3-L Repeated Blocks at some length in several of the Web &amp;
Software meetings (and I believe you and I chatted some about this as
well). It should really remain limited to web pages. Better in my
opinion would be something that talked about structure in content, and
ways of navigating that structure. Skipping repeated blocks is a kludge
that we've created for web pages. At worst, it should remain contained
to that sphere. At best, it should go away to be replaced by something
that talks to structure.

Likewise, we discussed Link Purpose, and again decided it was
appropriately limited to web pages. Not all content formats provide the
mechanisms that HTML does for exposing information about links. Our
content provisions don't require it. And while links are appearing in
programs, again, our AT-IT provision (the "accessibility services"
information) doesn't specify a certain amount of link-related
information be provided. We cannot expand 3-M to more than web without
other changes elsewhere.

Finally, for 3-H, I thought we came to the conclusion that using
identical icon bitmaps was not something needed anymore for screen
reader compatibility, which is why we took that out as a software
provision. With your change, it seems you are bringing it back in.

Also, separately, I worry about testability of this provision (3-H). Can
you give me a few examples of "components that have the same
functionality" and how they would be identified consistently? Are we
talking about two "Print" buttons that must both say "Print" because
they both print the same thing? Or if we have a "Print whole document"
and "Print this page" button, the buttons must look generally the same
and both have the word "Print" at the start it the same font, etc.?


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.

</pre>
<blockquote type="cite">
<pre wrap="">While this discussion of the definition of a 'web page' is sincerely
fascinating, like a broken record may I suggest again that we
eliminate it. All we accomplish by persisting the 'web' bucket is
creating a line that is at best artificial, or at worst so technical
that nobody will be able to interpret it anyway. We are spending
valuable brain power on something that in no way benefits a PwD.

There are only 3 provisions currently containing the word 'web',
listed below. After the August 17th text of each, I have listed what
the text could be if we de-'web'ed it. In situations where they may
not be applicable (i.e. my product has no links or repeated blocks) I
think it is simple enough for a developer/author/procurer to readily
determine that it is Not Applicable.


3-H - Consistent Identification

Current: Components that have the same functionality within a set of
Web pages must be identified consistently.
Proposed: Components that have the same functionality must be
identified consistently.


3-L - Repeated Blocks

Current: On Web pages, a mechanism must be available to bypass blocks
of content that are repeated on multiple Web pages.
Proposed: A mechanism must be available to bypass blocks of content
that are repeated.


3-M - Link Purpose

Current: On Web pages, it must be possible to determine the purpose of
each link from the link text or the link text together with its
programmatically determined link context.
Proposed: It must be possible to determine the purpose of each link
from the link text or the link text together with its programmatically
determined link context.

Peter Wallack
Accessibility Program Director
Oracle Corporation


Robinson, Norman B - Washington, DC wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This really makes me wish we could approach "web pages" as specific
file formats. As defined by WCAG, the "web page" is in effect a
subset of a "resource". The snake is eating it's tail.
Determining if something is a web page or an application embedded
and/or linked in a web page is different in truth and in perspective.
Where plugins was a good conceptual abstraction used in the past,
many browsers include support for formats internal to the browser
itself now - it is a part of the browser application. Desktop
software applications can install a plugin into the browser to either
be configured to start (run) the application using the dedicated
software application or keep the data "inside the browser". Add to
that "user agents" can be web browsers or dedicated applications that
use URI to load content. There are many examples of file formats that
can stand alone (have dedicated software for creation of that file
format) but we also have web browsers that can manipulate the file
format because it is built into the browser (e.g., support for
MathML, SVG).
Email is a good debate that we have continued to have for some time.
I assert that sending a HTML based email is *web content*. Arguing
that the email format also includes a text version or that their are
email clients that can reformat the HTML into plain text doesn't
escape the fact the email is created using HTML, in a HTML format,
and viewable "in a web browser". If we don't try and debate the point
that the sender doesn't know what the receive has, we should at least
be able to agree that if you compose an email using software that
creates it in a HTML format, that format should be considered as a
web page. Or at least I'm stubborn enough to keep trying to convince
everyone. :)
I think defining web pages as a specific file format (e.g., HTML,
XHTML, maybe XML or SGML depending on your degree of conviction and
abstraction) instead of thinking of web pages as all of the rendered
content is a better approach. Put another way, if you have a web page
or web application and a specific portion of it doesn't render (think
Youtube when you have no support for flash/avi) in the client/user
agent/browser is it still a web page? I think it is. If you didn't
have PNG support in your browser and everything rendered best it
could, but you couldn't see those images, would it still be a web
page? Yes, indeed it would.
So when is a web page not a web page? I content when it breaks and
doesn't parse is ultimately the best approach. That leads to
validation. However, I /*think well-formed is good enough*/ to prove
you have a web page. That requires specific tags closed as needed.
Is this a web page: &lt;/html&gt; ? Or is this a web page: &lt;html&gt; &lt;/html&gt; ?
Or is this a web page:
&lt;html&gt;&lt;head&gt;test&lt;/head&gt;&lt;alink=<a class="moz-txt-link-rfc2396E" href="http://linktosomeawfulproprietystreamingfileformat">"http://linktosomeawfulproprietystreamingfileformat"</a>&gt;webcastdemo&lt;/a&gt;&lt;/html
<a class="moz-txt-link-rfc2396E" href="http://linktosomeawfulproprietystreamingfileformat%22%3Ewebcastdemo%3C/a%3E%3C/html">&lt;http://linktosomeawfulproprietystreamingfileformat%22%3Ewebcastdemo%3C/a%3E%3C/html&gt;</a>&gt;
So I use the word "valid" to describe well-formed. Do not confuse
that with *validation*. I never said the act of validation has
occurred, only that if it did, it should work. Validation may require
a schema to check against or a parser that guesses correctly against
a known standard (that pesky specific file format I keep mentioning).
By being valid, you have a whole document that can stand alone. It
may link to other content (embedded links such as inline images are
links by-the-way) but can render without any links. We should have
valid web pages. We should define web pages as specific file formats.
In this way we can assign the responsibility for accessibility into
the file formats themselves (that part of web pages that aren't web
pages). Consider if the alt text is a part of the web page, then you
don't need the images. The web page doesn't "break" if the image is
unavailable - it doesn't render fully, true - it is still a web page.
And yes, browsers should allow content to "break" if they aren't
valid. And yes, you could validate but I'm not going into the
discussion that validation is required for accessibility in this email.
In closing, we should consider web pages as stand alone document
(file formats) for one other reason. When it is asserted that the
Section 508 standards clearly tell you what is accessible and what
technical standards apply, you have to apply them to the specific
file format or application. The current reference for "web page" or
"web application" could include N number of technologies and file
formats (software and web standards) which is currently useless for
discussing accessibility until you parse out the total file formats,
the total technologies, and evaluate their accessibility individually
(think a web page with flash, embedded QuickTime, embedded avi, mp3,
SVG. That is five technologies, all which require specific techniques
peculiar to their specific formats to provide accessibility). If we
define a web page as a file format and valid document only, then you
can easily see what is required by the web standards and drive people
to think about the specific non-web page formats in terms of
individually separate software.
Regards,

Norman B. Robinson
Section 508 Coordinator
IT Governance, US Postal Service
phone: 202.268.8246

-----Original Message-----
*From:* <a class="moz-txt-link-abbreviated" href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>
[<a class="moz-txt-link-freetext" href="mailto: = EMAIL ADDRESS REMOVED = ">mailto: = EMAIL ADDRESS REMOVED = </a>] *On Behalf Of
*Gregg Vanderheiden
*Sent:* Wednesday, August 22, 2007 2:31 PM
*To:* 'TEITAC Web/Software Subcommittee'
*Subject:* [teitac-websoftware] Action Item #2 - Definition of Web Page

Here is the current definition of Web Page from WCAG. It sounds
technical but it is interestingly difficult to define accurately.
Also, resources like an image may not be referenced on a site but
may be cited by others. Thus the phrase “scope of conformance” is
important so that a site it not responsible for accessibility of
pieces of web pages that are pulled from the site and posted by
others.

The rationale for the other aspects of the term can also be
provided if desired. They will all be in our support document for
WCAG “Understanding WCAG 2.0” as well.


*/Web page/*

a non-embedded resource, that is referenced by a URI within the
scope of conformance, plus any other resources that are used in
the rendering or intended to be rendered together with it"

*Note*: Although any "other resources" would be rendered together
with the primary resource, they would not necessarily be rendered
simultaneously with each other.

*Example* 1: When you enter <a class="moz-txt-link-freetext" href="http://shopping.example.com/">http://shopping.example.com/</a> in your
browser you enter a movie-like interactive shopping environment
where you visually move about a store dragging products off of
the shelves around you into a visual shopping cart in front of
you. Clicking on a product causes it to be demonstrated with a
specification sheet floating alongside.

*Example* 2: A Web resource including all embedded images and media.

*Example* 3: A Web mail program built using Asynchronous
JavaScript and XML (AJAX). The program lives entirely at
<a class="moz-txt-link-freetext" href="http://mail.example.com">http://mail.example.com</a>, but includes an inbox, a contacts area
and a calendar. Links or buttons are provided that cause the the
inbox, contacts, or calendar to display, but do not change the
URL of the page as a whole.

*Example* 4: A customizable portal site, where users can choose
content to display from a set of different content modules.


*/Resource/*

A network data object or service that can be identified by a URI
<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier">&lt;http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier&gt;</a>.
Resources may be available in multiple representations (e.g.
multiple languages, data formats, size, resolutions) or vary in
other ways.

(This term was taken verbatim from Hypertext Transfer Protocol --
HTTP/1.1 <a class="moz-txt-link-rfc2396E" href="http://www.w3.org/TR/di-gloss/#ref-http">&lt;http://www.w3.org/TR/di-gloss/#ref-http&gt;</a>)


Gregg

------------------------

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. &amp; BioMed Engr.
Director - Trace R &amp; D Center
University of Wisconsin-Madison
_<a class="moz-txt-link-rfc2396E" href="http://trace.wisc.edu/">&lt;http://trace.wisc.edu/&gt;</a>_ FAX 608/262-8848

DSS Player at <a class="moz-txt-link-freetext" href="http://tinyurl.com/dho6b">http://tinyurl.com/dho6b</a>

If Attachement is a mail.dat try <a class="moz-txt-link-freetext" href="http://www.kopf.com.br/winmail/">http://www.kopf.com.br/winmail/</a>

<a class="moz-txt-link-rfc2396E" href="http://trace.wisc.edu:8080/mailman/listinfo/">&lt;http://trace.wisc.edu:8080/mailman/listinfo/&gt;</a>

------------------------------------------------------------------------

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