Expanding the web's potential for people with disabilities

Getting Started

Introduction to web accessibility

WebAIM Training

May 21-22
Training Details

From the Blog

Community

You are here: Home > TEITAC Archives > Mailing List Archives

Thread Subject: 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.

Return to this mailing list's archives

Next message

From: Gregg Vanderheiden
Date: Wed, Aug 22 2007 12:35 PM
Subject: 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 http://shopping.example.com/ 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 http://mail.example.com, 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
<http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier> . 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://www.w3.org/TR/di-gloss/#ref-http> HTTP/1.1)

Gregg

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

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>

Previous message | Next message

From: Li, Alex
Date: Wed, Aug 22 2007 5:10 PM
Subject: Action Item #2 - Definition of Web Page

Here's the problem with a defintion like that--almost anything is web
content. When we cast such a wide net. The term just does not mean
much anymore.

Let's look at two scenarios to illustrate the point that thing not
intended to be web content can end up becoming web content.

Scenario 1-I think an exe file posted for download can be classified as
web content as it stands. Obviously, it does not make common sense that
an exe file posted would be considered as web conent. Please correct me
if I'm wrong.

Another common scenario that may test our understanding is email. A
simple text-based email application is generally not considered a web
authoring tool. Nor is an email author normally considered a web
content author. But the email author may become a web content author
because the receiver of the email happens to use a web-based email as
sited in example 3. Today, WCAG 2 carve that out as partial conformance
because the web-mail application cannot control the incoming emails. I
don't think we should do the same in 508. Below is the text used in
WCAG 2 for partial conformance.

Statement of partial conformance

Sometimes, Web pages are created that will later have additional content
added to them. For example, an email program, a blog, an article that
allows users to add comments to the bottom, or applications supporting
user contributed content. Another example would be a page composed of
content aggregated from multiple contributors, such as in portals and
news sites. Sometimes, the content from the other sources is
automatically inserted into the page over time.

In both of these cases, it is not possible to know at the time of
original posting what the content of the pages will be. Two options are
available:

1. A conformance claim is made based on best knowledge. If a page of
this type is monitored and kept conforming (non-conforming content is
immediately removed or made conforming) then a conformance claim can be
made since, except for error periods, the page conforms. No conformance
claim should be made if it is not possible to monitor or correct
non-conforming content; OR
2. A "statement of partial conformance" is made. A statement that the
page does not conform, but could conform if certain parts were removed
can be made. The form of that statement would be, "This page would
conform to WCAG 2.0 at level X if the following parts from uncontrolled
sources were removed."
a. The content that is excluded in the statement of partial
conformance cannot be content that is under the author's control.
b. The content that is excluded in the statement of partial
conformance would be described in terms that users can understand. (e.g.
they can't be described as "all parts that we do not have control of"
unless they are clearly marked as such.)

Previous message | Next message

From: Gregg Vanderheiden
Date: Thu, Aug 23 2007 1:10 AM
Subject: Re: Action Item #2 - Definition of Web Page

Hmmm

Both of the examples (.exe and email) would fail to be a Web Page under the
example.

An email viewer that was a web page- would be a web page. But the email is
not.. Nor is the EXE or any other downloaded file because they are not
rendered (by a user agent) - they are run.

If the word 'rendered' is unclear by itself - perhaps we should add "by a
user agent" to the end of the definition. Does that help?

With regard to content from multiple places --- it is true that sometimes it
is hard to make sure that web pages are accessible or stay accessible. But
that should not change the definition of what is a Web page -- nor when it
is accessible. It would only highlight the problem that people with
disabilities may have in successfully accessing some pages. And 508
standards should correctly identify which pages would cause problems.

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Li, Alex
> Sent: Wednesday, August 22, 2007 6:05 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: [teitac-websoftware] Action Item #2 - Definition of Web Page
>
> Here's the problem with a defintion like that--almost
> anything is web content. When we cast such a wide net. The
> term just does not mean much anymore.
>
> Let's look at two scenarios to illustrate the point that
> thing not intended to be web content can end up becoming web content.
>
> Scenario 1-I think an exe file posted for download can be
> classified as web content as it stands. Obviously, it does
> not make common sense that an exe file posted would be
> considered as web conent. Please correct me if I'm wrong.
>
> Another common scenario that may test our understanding is
> email. A simple text-based email application is generally
> not considered a web authoring tool. Nor is an email author
> normally considered a web content author. But the email
> author may become a web content author because the receiver
> of the email happens to use a web-based email as sited in
> example 3. Today, WCAG 2 carve that out as partial
> conformance because the web-mail application cannot control
> the incoming emails. I don't think we should do the same in
> 508. Below is the text used in WCAG 2 for partial conformance.
>
> Statement of partial conformance
>
> Sometimes, Web pages are created that will later have
> additional content added to them. For example, an email
> program, a blog, an article that allows users to add comments
> to the bottom, or applications supporting user contributed
> content. Another example would be a page composed of content
> aggregated from multiple contributors, such as in portals and
> news sites. Sometimes, the content from the other sources is
> automatically inserted into the page over time.
>
> In both of these cases, it is not possible to know at the
> time of original posting what the content of the pages will
> be. Two options are
> available:
>
> 1. A conformance claim is made based on best knowledge. If
> a page of this type is monitored and kept conforming
> (non-conforming content is immediately removed or made
> conforming) then a conformance claim can be made since,
> except for error periods, the page conforms. No conformance
> claim should be made if it is not possible to monitor or
> correct non-conforming content; OR
> 2. A "statement of partial conformance" is made. A
> statement that the page does not conform, but could conform
> if certain parts were removed can be made. The form of that
> statement would be, "This page would conform to WCAG 2.0 at
> level X if the following parts from uncontrolled sources were
> removed."
> a. The content that is excluded in the statement of
> partial conformance cannot be content that is under the
> author's control.
> b. The content that is excluded in the statement of
> partial conformance would be described in terms that users
> can understand. (e.g.
> they can't be described as "all parts that we do not have control of"
> unless they are clearly marked as such.)
>
>
>

Previous message | Next message

From: Robinson, Norman B - Washington, DC
Date: Thu, Aug 23 2007 6:10 AM
Subject: Re: Action Item #2 - Definition of Web Page

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: </html> ? Or is this a web page: <html> </html> ?
Or is this a web page:
<html><head>test</head><alink="http://linktosomeawfulproprietystreamingf
ileformat">webcastdemo</a></html>

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: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] 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 http://shopping.example.com/ 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
http://mail.example.com, 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
<http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier> .
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 <http://www.w3.org/TR/di-gloss/#ref-http> )

Gregg

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

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
<http://trace.wisc.edu/ <http://trace.wisc.edu/> > FAX
608/262-8848

DSS Player at http://tinyurl.com/dho6b

If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
<http://www.kopf.com.br/winmail/>

<http://trace.wisc.edu:8080/mailman/listinfo/>

Previous message | Next message

From: Peter Wallack
Date: Thu, Aug 23 2007 10:15 AM
Subject: Re: Action Item #2 - Definition of Web Page

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<big>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. </big><big>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. 
 
</big><big>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. 
</big> 
 
<h4>3-H - Consistent Identification</h4>
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. 

<h4> 3-L - Repeated Blocks </h4>
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. 

<h4> 3-M - Link Purpose</h4>
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. 

<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
 
 
Robinson, Norman B - Washington, DC wrote:
<blockquote
cite="mid: = EMAIL ADDRESS REMOVED = "
type="cite">
<title>Message</title>
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.2900.2912" name="GENERATOR">
<o:SmartTagType name="State"
namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType><o:SmartTagType
name="place" namespaceuri="urn:schemas-microsoft-com:office:smarttags"></o:SmartTagType>
<style>@font-face {
font-family: Wingdings;
}
@font-face {
font-family: Batang;
}
@font-face {
font-family: Kartika;
}
@font-face {
font-family: Tahoma;
}
@font-face {
font-family: Coronet;
}
@font-face {
font-family: Monotype Corsiva;
}
@font-face {
font-family: @Batang;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
H1 {
FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: Arial
}
H2 {
FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt; FONT-STYLE: italic; FONT-FAMILY: Arial
}
H3 {
FONT-WEIGHT: bold; FONT-SIZE: 13pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: Arial
}
H4 {
FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: "Times New Roman"
}
P.MsoFooter {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoFooter {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoFooter {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
P.MsoListBullet3 {
FONT-SIZE: 12pt; MARGIN: 0in 0in 6pt 0.75in; TEXT-INDENT: -0.25in; FONT-FAMILY: "Times New Roman"; mso-list: l1 level1 lfo3
}
LI.MsoListBullet3 {
FONT-SIZE: 12pt; MARGIN: 0in 0in 6pt 0.75in; TEXT-INDENT: -0.25in; FONT-FAMILY: "Times New Roman"; mso-list: l1 level1 lfo3
}
DIV.MsoListBullet3 {
FONT-SIZE: 12pt; MARGIN: 0in 0in 6pt 0.75in; TEXT-INDENT: -0.25in; FONT-FAMILY: "Times New Roman"; mso-list: l1 level1 lfo3
}
P.MsoListNumber2 {
FONT-SIZE: 12pt; MARGIN: 0in 0in 6pt; TEXT-INDENT: 0in; FONT-FAMILY: "Times New Roman"; mso-list: l0 level1 lfo5
}
LI.MsoListNumber2 {
FONT-SIZE: 12pt; MARGIN: 0in 0in 6pt; TEXT-INDENT: 0in; FONT-FAMILY: "Times New Roman"; mso-list: l0 level1 lfo5
}
DIV.MsoListNumber2 {
FONT-SIZE: 12pt; MARGIN: 0in 0in 6pt; TEXT-INDENT: 0in; FONT-FAMILY: "Times New Roman"; mso-list: l0 level1 lfo5
}
P.MsoTitle {
FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: center
}
LI.MsoTitle {
FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: center
}
DIV.MsoTitle {
FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: center
}
A:link {
COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
COLOR: purple; TEXT-DECORATION: underline
}
P.MsoDocumentMap {
FONT-SIZE: 10pt; BACKGROUND: navy; MARGIN: 0in 0in 0pt; FONT-FAMILY: Tahoma
}
LI.MsoDocumentMap {
FONT-SIZE: 10pt; BACKGROUND: navy; MARGIN: 0in 0in 0pt; FONT-FAMILY: Tahoma
}
DIV.MsoDocumentMap {
FONT-SIZE: 10pt; BACKGROUND: navy; MARGIN: 0in 0in 0pt; FONT-FAMILY: Tahoma
}
P {
FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
P.AbstractBullets {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; FONT-FAMILY: "Times New Roman"; mso-list: l3 level1 lfo1
}
LI.AbstractBullets {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; FONT-FAMILY: "Times New Roman"; mso-list: l3 level1 lfo1
}
DIV.AbstractBullets {
FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.75in; TEXT-INDENT: -0.25in; FONT-FAMILY: "Times New Roman"; mso-list: l3 level1 lfo1
}
P.SingleSpaceListing {
FONT-SIZE: 12pt; MARGIN: 0in 0in 3pt 1in; TEXT-INDENT: -0.25in; FONT-FAMILY: "Times New Roman"; mso-list: l2 level2 lfo6
}
LI.SingleSpaceListing {
FONT-SIZE: 12pt; MARGIN: 0in 0in 3pt 1in; TEXT-INDENT: -0.25in; FONT-FAMILY: "Times New Roman"; mso-list: l2 level2 lfo6
}
DIV.SingleSpaceListing {
FONT-SIZE: 12pt; MARGIN: 0in 0in 3pt 1in; TEXT-INDENT: -0.25in; FONT-FAMILY: "Times New Roman"; mso-list: l2 level2 lfo6
}
SPAN.EmailStyle25 {
COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
P.prefix {
FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
LI.prefix {
FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
DIV.prefix {
FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
DIV.Section1 {
page: Section1
}
OL {
MARGIN-BOTTOM: 0in
}
UL {
MARGIN-BOTTOM: 0in
}
</style>
<div>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.</div>
<div> </div>
<div>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).</div>
<div> </div>
<div>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. :)</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div>Is this a web page: </html> ?  Or is this
a web page: <html> </html> ? Or is this a web page:
<html><head>test</head><alink="<a
moz-do-not-send="true"
href="http://linktosomeawfulproprietystreamingfileformat%22%3Ewebcastdemo%3C/a%3E%3C/html">http://linktosomeawfulproprietystreamingfileformat">webcastdemo</a></html</a>></div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Regards,</div>
<div> </div>
<div> </div>
<div>
Norman B. Robinson
 
Section 508 Coordinator 
IT Governance, US Postal
Service 
phone: 202.268.8246

</div>
<div> </div>
<div>-----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 
 
</div>
<blockquote dir="ltr" style="margin-right: 0px;">
<div class="Section1">
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. <o:p></o:p>
<o:p> </o:p>
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. <o:p></o:p>
<o:p> </o:p>
<h2>Web
page<o:p></o:p></h2>
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" <o:p></o:p>
Note:
Although any "other resources" would be rendered together with the
primary resource, they would not necessarily be rendered simultaneously
with each other.<o:p></o:p>
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.<o:p></o:p>
Example
2: A Web resource including all embedded images and media.<o:p></o:p>
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.<o:p></o:p>
Example
4: A customizable portal site, where users can choose content to
display from a set of different content modules.<o:p></o:p>
<o:p> </o:p>
<h2>Resource<o:p></o:p></h2>
A
network data object or service that can be identified by a <a
moz-do-not-send="true"
href="http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier">URI</a>.
Resources may be available in multiple representations (e.g. multiple
languages, data formats, size, resolutions) or vary in other ways.<o:p></o:p>
(This
term was taken verbatim from <a moz-do-not-send="true"
href="http://www.w3.org/TR/di-gloss/#ref-http">Hypertext Transfer
Protocol -- HTTP/1.1</a>)<o:p></o:p>
<o:p> </o:p>
<o:p> </o:p>
<o:p> </o:p>
 
Gregg 
 
------------------------<o:p></o:p>
Gregg C
Vanderheiden Ph.D. 
Professor - Depts of <ns0:State
w:endinsdate="2007-08-22T12:58:00Z" w:endinsauthor="Gregg Vanderheiden"
w:insdate="2007-08-22T12:58:00Z" w:insauthor="Gregg Vanderheiden"><ns0:place
w:endinsdate="2007-08-22T12:58:00Z" w:endinsauthor="Gregg Vanderheiden"
w:insdate="2007-08-22T12:58:00Z" w:insauthor="Gregg Vanderheiden"><st1:State
w:st="on"><st1:place w:st="on">Ind.</st1:place></st1:State></ns0:place></ns0:State>
Engr. & BioMed Engr. 
Director - Trace R & D Center 
University of
Wisconsin-Madison 
<<a
moz-do-not-send="true" href="http://trace.wisc.edu/" target="_blank">http://trace.wisc.edu/</a>>
FAX 608/262-8848  <o:p></o:p>
DSS Player at <a moz-do-not-send="true"
href="http://tinyurl.com/dho6b">http://tinyurl.com/dho6b</a> <o:p></o:p>
If Attachement is a
mail.dat try <a moz-do-not-send="true"
href="http://www.kopf.com.br/winmail/">http://www.kopf.com.br/winmail/</a><o:p></o:p>
<a moz-do-not-send="true"
href="http://trace.wisc.edu:8080/mailman/listinfo/"> <o:p></o:p></a>
<o:p> </o:p>
<o:p> </o:p>
</div>
</blockquote>
<pre wrap="">
<hr size="4" width="90%">

Previous message | Next message

From: Gregg Vanderheiden
Date: Thu, Aug 23 2007 12:20 PM
Subject: Re: Action Item #2 - Definition of Web Page

Thanks Peter

On a separate note I pointed out that we only have three provisions that
are Web specific. And that seemed like we just needed to generalize them
like the rest.

This goes a long way in that direction.

We need some scoping on these (2 of your suggestions) though or they
might imply that all controls used everywhere must be consistent.

Perhaps if we add the word "within a product" to them it would work.
Even 'set of web pages' could be thought of as a product.

That would give us

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 within a product.

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 within a product.

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.

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Peter
Wallack
Sent: Thursday, August 23, 2007 11:13 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Action Item #2 - Definition of Web Page

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:

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: </html> ? Or is this a web page: <html> </html> ? Or is
this a web page:
<html><head>test</head><alink="http://linktosomeawfulproprietystreamingfilef
ormat
<http://linktosomeawfulproprietystreamingfileformat%22%3Ewebcastdemo%3C/a%3E
%3C/html> ">webcastdemo</a></html>

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: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] 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 http://shopping.example.com/ 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 http://mail.example.com, 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
<http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier> . 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
<http://www.w3.org/TR/di-gloss/#ref-http> )

Gregg

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

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>

_____

size=4 width="90%" align=center>

Previous message | Next message

From: Peter Wallack
Date: Thu, Aug 23 2007 12:50 PM
Subject: Re: Action Item #2 - Definition of Web Page

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Gregg -- 
No objections to adding the scoping clause. And I wouldn't object to
adding similar wording to some others too, especially those that imply
an IT vendor is responsible for the entire ecosystem. ;-) 
 
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
 
 
Gregg Vanderheiden wrote:
<blockquote cite="mid:007201c7e5b1$96425490$05000100@NC84301"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator" content="Microsoft Word 11 (filtered medium)">

<title>Message</title>
<o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="State">
<o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"><o:SmartTagType
namespaceuri="urn:schemas-microsoft-com:office:smarttags"
name="PersonName">

<style>

</style>
</o:SmartTagType></o:SmartTagType></o:SmartTagType>
<div class="Section1">
<div>
Thanks Peter<o:p></o:p>
<o:p> </o:p>
<o:p> </o:p>
On a separate note I pointed
out that we only have
three  provisions that are Web specific.  And that seemed like we
just needed to generalize them like the rest.<o:p></o:p>
<o:p> </o:p>
This goes a long way in that
direction.<o:p></o:p>
<o:p> </o:p>
   We need some scoping on
these (2 of your
suggestions) though or they might imply that all controls used
everywhere must
be consistent. <o:p></o:p>
<o:p> </o:p>
Perhaps if we add the word 
“within a product”
to them it would work.    Even ‘set of web pages’
could be thought of as a product.  <o:p></o:p>
<o:p> </o:p>
That would give us <o:p></o:p>
</div>
<div>
 <o:p></o:p>
<h4>3-H -
Consistent Identification<o:p></o:p></h4>
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 within
a
product.<o:p></o:p>
<h4>3-L -
Repeated Blocks <o:p></o:p></h4>
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 within
a product.<o:p></o:p>
<h4>3-M -
Link Purpose<o:p></o:p></h4>
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.<o:p></o:p>
<o:p> </o:p>
</div>
 
Gregg 
 --
------------------------------ 
Gregg C
Vanderheiden Ph.D. <o:p></o:p>
<div>
 <o:p></o:p>
</div>
<blockquote
style="border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color black; border-width: medium medium medium 1.5pt; margin: 5pt 0in 5pt 3.75pt; padding: 0in 0in 0in 4pt;">
<o:p> </o:p>
<div class="MsoNormal" style="text-align: center;" align="center">
<hr tabindex="-1" align="center" size="2" width="100%"></div>
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 Peter Wallack 
Sent: Thursday,
August 23, 2007
11:13 AM 
To: <st1:PersonName
w:st="on">TEITAC Web/Software Subcommittee</st1:PersonName> 
Subject: Re:
[teitac-websoftware]
Action Item #2 - Definition of Web Page<o:p></o:p>
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. <o:p></o:p>
<h4>3-H -
Consistent Identification<o:p></o:p></h4>
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.<o:p></o:p>
<h4>3-L -
Repeated Blocks <o:p></o:p></h4>
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.<o:p></o:p>
<h4>3-M -
Link Purpose<o:p></o:p></h4>
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.<o:p></o:p>
<pre cols="72">Peter Wallack<o:p></o:p></pre>
<pre>Accessibility Program Director<o:p></o:p></pre>
<pre>Oracle Corporation<o:p></o:p></pre>
 
 
Robinson, Norman B - Washington, DC wrote: <o:p></o:p>
<div>
<O:SMARTTAGTYPE
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="State"></O:SMARTTAGTYPE><O:SMARTTAGTYPE
namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"></O:SMARTTAGTYPE>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.<o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
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).<o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
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. :)<o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
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.<o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
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.<o:p></o:p>
</div>
<div>
Is this a
web page:
</html> ?  Or is this a web page: <html> </html> ?
Or is this a web page:
<html><head>test</head><alink="<a
href="http://linktosomeawfulproprietystreamingfileformat%22%3Ewebcastdemo%3C/a%3E%3C/html"
moz-do-not-send="true">http://linktosomeawfulproprietystreamingfileformat">webcastdemo</a></html</a>><o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
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.<o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
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.<o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
Regards,<o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
Norman B.
Robinson 
Section 508
Coordinator 
IT
Governance, US Postal Service 
phone:
202.268.8246
<o:p></o:p>
</div>
<div>
 <o:p></o:p>
</div>
<div>
-----Original
Message----- 
From: <a
moz-do-not-send="true"
href="mailto: = EMAIL ADDRESS REMOVED = "> = EMAIL ADDRESS REMOVED = </a>
[<a moz-do-not-send="true"
href="mailto: = EMAIL ADDRESS REMOVED = ">mailto: = EMAIL ADDRESS REMOVED = </a>]
On Behalf Of Gregg
Vanderheiden 
Sent: Wednesday,
August 22, 2007
2:31 PM 
To: '<st1:PersonName
w:st="on">TEITAC Web/Software Subcommittee</st1:PersonName>' 
Subject:
[teitac-websoftware]
Action Item #2 - Definition of Web Page<o:p></o:p>
</div>
<blockquote
style="margin-top: 5pt; margin-right: 0in; margin-bottom: 5pt;">
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. <O:P></O:P><o:p></o:p>
<O:P></O:P>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. <O:P></O:P><o:p></o:p>
<h2><O:P></O:P>Web
page<O:P></O:P><o:p></o:p></h2>
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" <O:P></O:P><o:p></o:p>
Note:
Although any "other resources" would be rendered together with the
primary
resource, they would not necessarily be rendered simultaneously with
each other.<o:p></o:p><O:P></O:P>
Example
1: When you enter <a moz-do-not-send="true"
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.<o:p></o:p><O:P></O:P>
Example
2: A Web resource including all embedded images and media.<o:p></o:p><O:P></O:P>
Example
3: A Web mail program built using Asynchronous JavaScript and XML
(AJAX). The
program lives entirely at <a moz-do-not-send="true"
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.<o:p></o:p><O:P></O:P>
Example
4: A customizable portal site, where users can choose content to
display from a
set of different content modules.<o:p></o:p><O:P></O:P>
<h2><O:P></O:P>Resource<o:p></o:p><O:P></O:P></h2>
A network data object or
service that can be identified by a <a
href="http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier"
moz-do-not-send="true">URI</a>. Resources may be available in multiple
representations (e.g. multiple languages, data formats, size,
resolutions) or
vary in other ways.<O:P></O:P><o:p></o:p>
(This term was taken
verbatim from <a href="http://www.w3.org/TR/di-gloss/#ref-http"
moz-do-not-send="true">Hypertext Transfer Protocol -- HTTP/1.1</a>)<O:P></O:P><o:p></o:p>
<O:P></O:P> 
<O:P></O:P><O:P></O:P>Gregg 
 
------------------------<O:P></O:P><o:p></o:p>
Gregg C
Vanderheiden Ph.D. 
Professor
- Depts of <NS0:STATE u5:insauthor="Gregg Vanderheiden"
u5:insdate="2007-08-22T12:58:00Z" u5:endinsauthor="Gregg Vanderheiden"
u5:endinsdate="2007-08-22T12:58:00Z"><NS0:PLACE
u5:insauthor="Gregg Vanderheiden" u5:insdate="2007-08-22T12:58:00Z"
u5:endinsauthor="Gregg Vanderheiden"
u5:endinsdate="2007-08-22T12:58:00Z"><ST1:STATE u5:st="on"><ST1:PLACE
u5:st="on"><st1:State w:st="on"><st1:place w:st="on">Ind.</st1:place></st1:State></ST1:PLACE></ST1:STATE></NS0:PLACE></NS0:STATE>
Engr. & BioMed Engr. 
Director - Trace R & D Center 
University
of Wisconsin-Madison 
<<a
href="http://trace.wisc.edu/" target="_blank" moz-do-not-send="true">http://trace.wisc.edu/</a>>
FAX
608/262-8848  <O:P></O:P><o:p></o:p>
DSS Player at <a
href="http://tinyurl.com/dho6b" moz-do-not-send="true">http://tinyurl.com/dho6b</a>
<O:P></O:P><o:p></o:p>
If Attachement is a
mail.dat try <a href="http://www.kopf.com.br/winmail/"
moz-do-not-send="true">http://www.kopf.com.br/winmail/</a><O:P></O:P><o:p></o:p>
<O:P></O:P><o:p></o:p>
</blockquote>
<O:P></O:P>
<pre style="text-align: center;" wrap="">

<hr><O:P></O:P> size=4 width="90%" align=center>

</pre>
<pre><o:p> </o:p></pre>
<pre>

Previous message | Next message

From: Peter Korn
Date: Thu, Aug 23 2007 11:30 PM
Subject: Re: Action Item #2 - Definition of Web Page

Hi (other) Peter,

We discussed 3-L Repeated Blocks at some length in several of the Web &
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.

> 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:
>> 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: </html> ? Or is this a web page: <html> </html> ?
>> Or is this a web page:
>> <html><head>test</head><alink="http://linktosomeawfulproprietystreamingfileformat">webcastdemo</a></html
>> <http://linktosomeawfulproprietystreamingfileformat%22%3Ewebcastdemo%3C/a%3E%3C/html>>
>> 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:* = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] *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 http://shopping.example.com/ 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
>> http://mail.example.com, 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
>> <http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier>.
>> 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 <http://www.w3.org/TR/di-gloss/#ref-http>)
>>
>>
>> Gregg
>>
>> ------------------------
>>
>> Gregg C Vanderheiden Ph.D.
>> Professor - Depts of Ind. Engr. & BioMed Engr.
>> Director - Trace R & D Center
>> University of Wisconsin-Madison
>> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>>
>> DSS Player at http://tinyurl.com/dho6b
>>
>> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>>
>> <http://trace.wisc.edu:8080/mailman/listinfo/>
>>
>> ------------------------------------------------------------------------
>>
>>

Previous message | Next message

From: William Loughborough
Date: Thu, Aug 23 2007 11:35 PM
Subject: Re: Action Item #2 - Definition of Web Page

Peter Korn wrote:
> 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.
This is wonderful news. I've been really bothered by the "repeated
blocks" thing because it just doesn't make a big difference and because
determining what it is that gets repeated isn't quite as simple as it
might at first seem. If no way to "skip" is available it won't really
mess with anyone's access all that much, will it?

Lose it.

Love.

Previous message | Next message

From: David Poehlman
Date: Fri, Aug 24 2007 6:20 AM
Subject: Re: Action Item #2 - Definition of Web Page

In all of this well formed discussion, I can not see a special use for "web
page". If we make the content standards robust enough for instance,
removing skip blocks in favor of structure, attributing controls to
software, presenting clear directions on presentation, providing detailed
descriptions of the accessability of formats and technologies, describing
how to handle hypertext content no matter where it may be found and other
measures, we not only have a more robust set of standards, but when web
pages go away to be replaced with something else or are so far embedded into
e-life as to no longer be apparent, we will be there.

----- Original Message -----
From: "Peter Korn" < = EMAIL ADDRESS REMOVED = >
To: "TEITAC Web/Software Subcommittee" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, August 24, 2007 1:22 AM
Subject: Re: [teitac-websoftware] Action Item #2 - Definition of Web Page

Hi (other) Peter,

We discussed 3-L Repeated Blocks at some length in several of the Web &
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.

> 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:
>> 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: </html> ? Or is this a web page: <html> </html> ?
>> Or is this a web page:
>> <html><head>test</head><alink="http://linktosomeawfulproprietystreamingfileformat">webcastdemo</a></html
>> <http://linktosomeawfulproprietystreamingfileformat%22%3Ewebcastdemo%3C/a%3E%3C/html>>
>> 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:* = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] *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 http://shopping.example.com/ 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
>> http://mail.example.com, 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
>> <http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier>.
>> 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 <http://www.w3.org/TR/di-gloss/#ref-http>)
>>
>>
>> Gregg
>>
>> ------------------------
>>
>> Gregg C Vanderheiden Ph.D.
>> Professor - Depts of Ind. Engr. & BioMed Engr.
>> Director - Trace R & D Center
>> University of Wisconsin-Madison
>> _<http://trace.wisc.edu/>_ FAX 608/262-8848
>>
>> DSS Player at http://tinyurl.com/dho6b
>>
>> If Attachement is a mail.dat try http://www.kopf.com.br/winmail/
>>
>> <http://trace.wisc.edu:8080/mailman/listinfo/>
>>
>> ------------------------------------------------------------------------
>>
>>

Previous message | Next message

From: Peter Wallack
Date: Fri, Aug 24 2007 2:20 PM
Subject: Re: Action Item #2 - Definition of Web Page

<!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'. 
 
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: 
<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. 
</blockquote>
 
By making those changes, we still accomplish my goal: no reference to a
'web page' in the entire document. 
<pre class="moz-signature" cols="72">Peter Wallack
Accessibility Program Director
Oracle Corporation</pre>
 
 
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 &
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: </html> ? Or is this a web page: <html> </html> ?
Or is this a web page:
<html><head>test</head><alink=<a class="moz-txt-link-rfc2396E" href="http://linktosomeawfulproprietystreamingfileformat">"http://linktosomeawfulproprietystreamingfileformat"</a>>webcastdemo</a></html
<a class="moz-txt-link-rfc2396E" href="http://linktosomeawfulproprietystreamingfileformat%22%3Ewebcastdemo%3C/a%3E%3C/html"><http://linktosomeawfulproprietystreamingfileformat%22%3Ewebcastdemo%3C/a%3E%3C/html></a>>
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"><http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier></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"><http://www.w3.org/TR/di-gloss/#ref-http></a>)

Gregg

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

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
_<a class="moz-txt-link-rfc2396E" href="http://trace.wisc.edu/"><http://trace.wisc.edu/></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/"><http://trace.wisc.edu:8080/mailman/listinfo/></a>

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

Previous message | Next message

From: Peter Korn
Date: Fri, Aug 24 2007 3:50 PM
Subject: Re: 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

Previous message | Next message

From: Barrett, Don
Date: Sun, Aug 26 2007 9:35 PM
Subject: Re: 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

Previous message | Next message

From: Gregg Vanderheiden
Date: Sun, Aug 26 2007 10:35 PM
Subject: Re: Action Item #2 - Definition of Web Page

Yes a Web page is a resource. As is anything else fetched with a URI. The
difference is that to be a Web page it has to be a non-embedded resource.
The ROOT resource if you will.

Since a Web page can include other resources (some of which might be Web
pages in their own right) the definition needs to be carefully crafted.

But that is the nature of the web and web content. I'm not sure how you
see the snake eating its tail - because of the non-embedded clause. But it
does take careful reading.

I wish it weren't so hard to define. But it is. And since conformance is
based on it it is pretty important in WCAG - and somewhat important here.

But the line between Web Pages and applications is indeed blurring.
Fortunately, we do not need to differentiate with the new formulation of
TEITAC

Other comments below marked GV: (mostly to help with WCAG work)

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robinson,
Norman B - Washington, DC
Sent: Thursday, August 23, 2007 7:09 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Action Item #2 - Definition of Web Page

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.

GV: agree - and we do not call these content - but user agents.

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).

GV: again - agree. But these would be user agents rather than content. They
do not meet the definition of Web Page. (esp if amended with "with user
agent" on the end. Agree? Or do you see a loophole we missed.

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*.

GV: if not fetched using URI it would not meet our definition. (The view
might).

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. :)

GV: Help systems and other places also use HTML and aren't even connected
to the Internet. So according to our guidelines HTML does not constitute
Web. But the guidelines could still be quite useful there of course.

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.

GV: this would be too much and too little. Much Web is and will be in
other forms. And some HTML is not Web.

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: </html> ? Or is this a web page: <html> </html> ? Or is
this a web page: <html><head>test</head><alink="
<http://linktosomeawfulproprietystreamingfileformat>
http://linktosomeawfulproprietystreamingfileformat">webcastdemo</a></html>

GV: Well - if badly written Web pages aren't web pages then it would be hard
to contract for

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: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] 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 http://shopping.example.com/ 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 http://mail.example.com, 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
<http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier> . 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://www.w3.org/TR/di-gloss/#ref-http> HTTP/1.1)

Gregg

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

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at <http://tinyurl.com/dho6b> http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>

Previous message | Next message

From: David Poehlman
Date: Mon, Aug 27 2007 4:10 AM
Subject: Re: Action Item #2 - Definition of Web Page

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

Previous message | Next message

From: Robinson, Norman B - Washington, DC
Date: Mon, Aug 27 2007 3:15 PM
Subject: Re: Action Item #2 - Definition of Web Page

Gregg,

Thanks for taking the time to respond!

You said "Yes a Web page is a resource. As is anything else fetched
with a URI. The difference is that to be a Web page it has to be a
non-embedded resource. The ROOT resource if you will. ", is it really
the fact that it has to be fetched with a URI? Consider that I can fetch
a web page with http://www.usps.com/test.html. I can fetch the same
thing using a different URI ftp://www.usps.com/test.html. I could also
locally reference from another web page using those conventions or local
./test.html. In all scenarios I've simply obtained "test.html". The URI
(locator or names used) doesn't matter; it is a HTML file with the file
name of "test.html". Do you seriously intend that if it isn't fetched
-somehow- it isn't a web page? Even URI has reference for local files,
so again, how is this not a "web page"?

You also said the *view* of HTML based email might meet the
definition of a web page. Is this only because of the issue with how it
is loaded into the user agent (the URI issue)? Because I'd like to say
if we ask "is this accessible" the only way I would suggest to validate
is to use the technical standards as the test. E.g., I wouldn't throw
"alt text is required" out the window just because someone tried to
justify it as "HTML Help" or "HTML email" and therefore somehow not "web
HTML".

The next issue would be of whether it is a non-embedded resource.
How do you defined embedded? What is the definition? URIs can reference
streaming data, encapsulated files, embedded (validated to and against
the local HTML document) or non-embedded (URIs to external resources
that are not a part of "this" HTML document). An RFC or other reference
would probably help me understand so I don't keep annoying you with
requests for definitions. I really want to understand your point of
view.

Also, if I understand your reply, you relate plugins to be "user
agents" and not "content". So our question is, relevant to the
definition of web page, is content to be considered as part of the web
page following the Section 508 technical standards for web pages or is
the content to be considered as following Section 508 technical
standards for software?

You said some HTML is not web; could you provide me an example to
reference? You also mention the web is and will be in other forms, thus
defining web pages as specific file formats is "too much and too
little". What is too much? That we follow a standard validation schema?
What is too little? That we can have validation without accessibility?
I'm guessing from your reference to "if badly written web pages aren't
web pages" this is the validation issue. To which I'll repeat: if it
isn't well formed (and cannot be validated against a schema) then is
isn't a (valid) web page. If we contract for content, they better be
able to validate! To validate we must have file format definitions to
validate against. Thus, I hope to see web pages addressed as particular
file formats, with explicit instruction for conventions (e.g., alt text,
longdesc, table tags, etc.) in that format needed for accessibility.

Thanks again for taking the time to respond. I hope my continued
quest for clarity doesn't burden you.

Regards,

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

Previous message | Next message

From: Sean Hayes
Date: Tue, Aug 28 2007 8:55 AM
Subject: Re: Action Item #2 - Definition of Web Page

The definition of "web page" is definitely problematic.

Tying it to a 'root resource' is an interesting idea, but in the presence of frames it falls apart. If a resource is a web page in some contexts (e.g. you navigated directly to it from a search engine), but not in others (it is selected in a frameset by a menu page) then it hardly counts as a definition.

I'm beginning to think that searching for a technical definition is not going to succeed, ultimately a resource is a web page if the user (or author) perceives it as such.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385

From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg Vanderheiden
Sent: 27 August 2007 05:34
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Action Item #2 - Definition of Web Page

Yes a Web page is a resource. As is anything else fetched with a URI. The difference is that to be a Web page it has to be a non-embedded resource. The ROOT resource if you will.

Since a Web page can include other resources (some of which might be Web pages in their own right) the definition needs to be carefully crafted.

But that is the nature of the web and web content. I'm not sure how you see the snake eating its tail - because of the non-embedded clause. But it does take careful reading.

I wish it weren't so hard to define. But it is. And since conformance is based on it it is pretty important in WCAG - and somewhat important here.

But the line between Web Pages and applications is indeed blurring. Fortunately, we do not need to differentiate with the new formulation of TEITAC

Other comments below marked GV: (mostly to help with WCAG work)

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

Previous message |

From: Gregg Vanderheiden
Date: Tue, Aug 28 2007 2:45 PM
Subject: Re: Action Item #2 - Definition of Web Page

Hi Sean,

There are many resources that are embedded in one place but not another.
The definition still works. If the resource is used in a non-embedded
fashion anywhere on your site - it needs to conform. If it is embedded -
then the embedding page needs to conform.

This is how the definition would work.

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Sean Hayes
Sent: Tuesday, August 28, 2007 9:50 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Action Item #2 - Definition of Web Page

The definition of "web page" is definitely problematic.

Tying it to a 'root resource' is an interesting idea, but in the presence of
frames it falls apart. If a resource is a web page in some contexts (e.g.
you navigated directly to it from a search engine), but not in others (it is
selected in a frameset by a menu page) then it hardly counts as a
definition.

I'm beginning to think that searching for a technical definition is not
going to succeed, ultimately a resource is a web page if the user (or
author) perceives it as such.

Sean Hayes
Incubation Lab
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,

Mobile: +44 7875 091385

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: 27 August 2007 05:34
To: 'TEITAC Web/Software Subcommittee'
Subject: Re: [teitac-websoftware] Action Item #2 - Definition of Web Page

Yes a Web page is a resource. As is anything else fetched with a URI. The
difference is that to be a Web page it has to be a non-embedded resource.
The ROOT resource if you will.

Since a Web page can include other resources (some of which might be Web
pages in their own right) the definition needs to be carefully crafted.

But that is the nature of the web and web content. I'm not sure how you
see the snake eating its tail - because of the non-embedded clause. But it
does take careful reading.

I wish it weren't so hard to define. But it is. And since conformance is
based on it it is pretty important in WCAG - and somewhat important here.

But the line between Web Pages and applications is indeed blurring.
Fortunately, we do not need to differentiate with the new formulation of
TEITAC

Other comments below marked GV: (mostly to help with WCAG work)

Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robinson,
Norman B - Washington, DC
Sent: Thursday, August 23, 2007 7:09 AM
To: TEITAC Web/Software Subcommittee
Subject: Re: [teitac-websoftware] Action Item #2 - Definition of Web Page

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.

GV: agree - and we do not call these content - but user agents.

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).

GV: again - agree. But these would be user agents rather than content. They
do not meet the definition of Web Page. (esp if amended with "with user
agent" on the end. Agree? Or do you see a loophole we missed.

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*.

GV: if not fetched using URI it would not meet our definition. (The view
might).

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. :)

GV: Help systems and other places also use HTML and aren't even connected
to the Internet. So according to our guidelines HTML does not constitute
Web. But the guidelines could still be quite useful there of course.

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.

GV: this would be too much and too little. Much Web is and will be in
other forms. And some HTML is not Web.

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: </html> ? Or is this a web page: <html> </html> ? Or is
this a web page: <html><head>test</head><alink="
<http://linktosomeawfulproprietystreamingfileformat>
http://linktosomeawfulproprietystreamingfileformat">webcastdemo</a></html>

GV: Well - if badly written Web pages aren't web pages then it would be hard
to contract for

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: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] 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 http://shopping.example.com/ 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 http://mail.example.com, 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
<http://www.w3.org/TR/di-gloss/#def-uniform-resource-identifier> . 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://www.w3.org/TR/di-gloss/#ref-http> HTTP/1.1)

Gregg

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

Gregg C Vanderheiden Ph.D.
Professor - Depts of Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
< <http://trace.wisc.edu/> http://trace.wisc.edu/> FAX 608/262-8848

DSS Player at <http://tinyurl.com/dho6b> http://tinyurl.com/dho6b

If Attachement is a mail.dat try <http://www.kopf.com.br/winmail/>
http://www.kopf.com.br/winmail/

<http://trace.wisc.edu:8080/mailman/listinfo/>

WebAIM is an initiative of: