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: Gregg Vanderheiden
Date: Tue, Aug 28 2007 2:45 PM

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:
Center for Persons with Disabilities (CPD) Utah State University