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 Korn
Date: Thu, Aug 23 2007 11:30 PM

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/>
>>
>> ------------------------------------------------------------------------
>>
>>

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