Thread Subject: Re: Action Item #2 - Definition of Web Page

From: Gregg Vanderheiden
Date: Thu, Aug 23 2007 12:20 PM

• Return to this mailing list's archives
• View all messages in this thread
• Next message in thread: Peter Wallack: "Re: Action Item #2 - Definition of Web Page"
• Previous message in thread: Peter Wallack: "Re: Action Item #2 - Definition of Web Page"
• Messages sorted by: Author | Thread | Date

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>

• Next message in Thread: Peter Wallack: "Re: Action Item #2 - Definition of Web Page"
• Previous message in Thread: Peter Wallack: "Re: Action Item #2 - Definition of Web Page"