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: Robinson, Norman B - Washington, DC
Date: Mon, Aug 27 2007 3:15 PM

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

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