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: Re: Action Item #2 - Definition of Web Page

Note

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

From: Peter Wallack
Date: Thu, Aug 23 2007 10:15 AM

Return to this mailing list's archives
View all messages in this thread
Next message in thread: Gregg Vanderheiden: "Re: Action Item #2 - Definition of Web Page"
Previous message in thread: Robinson, Norman B - Washington, DC: "Re: Action Item #2 - Definition of Web Page"
Messages sorted by: Author | Thread | Date

<!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%">

Next message in Thread: Gregg Vanderheiden: "Re: Action Item #2 - Definition of Web Page"
Previous message in Thread: Robinson, Norman B - Washington, DC: "Re: Action Item #2 - Definition of Web Page"

WebAIM is an initiative of: