RE: PROPOSAL: Checkpoints related to TABLE accessibility

The checkpoint on fully exposing DOM is, at best, a technique.  It doesn't
say what functionality will be gained by doing this.  In fact, unless some
third party AT is reading the DOM, no added functionality would be provided
at all.

I think that all priority 1 items should be directly related to the
functionality that the checkpoint will provide to users with disabilities.

With regard to the DOM in particular, making this priority 1 would suggest
that this is the *only* way to provide access to web content, and I don't
think we can say that.

Denis Anson, MS, OTR
Assistant Professor
Computer Access Specialist
College Misericordia
301 Lake Street
Dallas, PA 18612

RESNA
The International Organization of Assistive Technology Professionals

Member since 1989

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
Behalf Of Charles Oppermann
Sent: Thursday, January 28, 1999 1:13 PM
To: Kathy Hewitt; 'Jon Gunderson'; w3c-wai-ua@w3.org
Subject: RE: PROPOSAL: Checkpoints related to TABLE accessibility


I agree with Kathy and her comments on the checkpoints, here are some more
comments...

<<
Checkpoint 6.1.4 [Priority 1]: Fully implement the Document Object Model
Level 1

Disagree.  This should be a Priority 2 item.  DOM Level 1 is not the only
way for Assistive Technologies to access a user agent.  Active Accessibility
is another way several screen readers support Internet Explorer.
>>

I agree with Kathy and will add another reason this shouldn't be priority 1.
Full support for any technology is a major undertaking and I'm sure that
neither Kathy or I want to sign up the Internet Explorer development team to
*fully* support anything.

We can't even support all of CSS1, and we have probably the biggest advocate
for CSS on the IE development team!  (Chris Wilson).  So, I'm very reluctant
to say that we will support anything fully.  Tell us what we must support
for accessibility purposes.

<<
Checkpoint 6.2.6 [Priority 1]: Provide a means for assistive technology to
access the user agents Document Object Model
>>

I'd also add that there are some technical and possible security issues
involved with this.  Should be priority 2 and even then might not be
feasible.  Although I think everyone agrees that if it possible, it would be
very cool.

<<
Checkpoint 4.3.3 [Priority 1 or 2]: Allow the user to request assumptions be
made about table header information when table header information is not
available or is incomplete.
>>

This seems vague, can I get a practical example of how this would work?

Thanks,
-Chuck
-----Original Message-----
From: Kathy Hewitt [mailto:kathyhe@microsoft.com]
Sent: Wednesday, January 27, 1999 8:38 AM
To: 'Jon Gunderson'; w3c-wai-ua@w3.org
Subject: RE: PROPOSAL: Checkpoints related to TABLE accessibility


General feedback.  These are good ideas, but most of them do not need to be
priority 1 items.  Let's keep pri-1 down to minimum requirements of a
browser to make it accessible rather than bloating it with feature requests
that would be nice to have to some, but doesn't make the browser
inaccessible.

Specific feedback on different checkpoints proposed:

Checkpoint 6.1.4 [Priority 1]: Fully implement the Document Object Model
Level 1

Disagree.  This should be a Priority 2 item.  DOM Level 1 is not the only
way for Assistive Technologies to access a user agent.  Active Accessibility
is another way several screen readers support Internet Explorer.  More
companies outside of Microsoft are adding MSAA support into their products
making it a "standard" way to access all different kinds of applications not
just specific to browsers.  Given that you have different methods to gain
access to HTML content, it is not appropriate to make DOM Level 1 support a
priority 1 item as I can provide concrete examples of other AT vendors not
using DOM but can support IE.

Checkpoint 6.2.6 [Priority 1]: Provide a means for assistive technology to
access the user agents Document Object Model

Disagree.  Should be Priority 2.  Following the same rationale as above.  If
DOM Level 1 support is not a priority 1 item then providing a means to
access it cannot be a pri-1 item either.

Checkpoint 6.2.7: [Priority 1]: Provide a means for the user to execute a
script at the end of loading (onload event in HTML 4.0 specification) and
document changed (may not be defined in current W3C standards) events.

Disagree.  Should be priority 2.  While I like the idea and think it would
be a cool feature, I don't think that not providing this functionality would
make the browser inaccessible.  This checkpoint was devised to support
legacy systems... Well, technology moves forward and AT technologies needs
to and in most cases has as well to meet consumers' needs.

Checkpoint 4.3.3 [Priority 1 or 2]: Allow the user to request assumptions be
made about table header information when table header information is not
available or is incomplete.

Should be Priority 2.  Not having this feature will not make the browser
inaccessible.  Invest the time to get author's to author correctly rather
than a browser (who displays the author's content) make guesses which could
be more confusing to the end user.

Checkpoint 5.5.3 [Priority 1]: Allow users to navigate between structural
elements of the document

Disagree.  Should be priority 2.  This would be a nice feature for some, but
would not make or break accessibility to the browser.  Users can still use
the browser if this feature is not present.

Checkpoint 5.2.7 [Priority 1 or 2] (modification of current checkpoint):
Provide the user with information about the about a table and the current
table cell

Should be priority 2.  This would be a nice feature for some, but would not
make or break accessibility to the browser.  Users can still use the browser
if this feature is not present.

Thanks
kathy


-----Original Message-----
From: Jon Gunderson [mailto:jongund@staff.uiuc.edu]
Sent: Friday, January 22, 1999 9:47 AM
To: w3c-wai-ua@w3.org
Subject: PROPOSAL: Checkpoints related to TABLE accessibility


This is a proposal for checkpoints related to Table Accessibility for
Desktop Graphical User Agent and Assistive Techmology Conformance.  The
conformance checkpoints for each are divided into sections that are clearly
marked.  There is NO single tables section of the current working draft,
therefore the checkpoints related to tables are listed under an appropriate
guideline for that checkpoint.  The guideline a checkpoint is listed under
is stated as part of this proposal.

Note: Some checkpoints listed in this proposal are more general than
providing access to table elements.

Please review and respond to the list.  We will discuss this and any other
proposals related to table access and conformance issues during the telecon
next week.
Jon


Checkpoints Related to Desktop Graphical User Agent Conformance for Tables
==========================================================

The following 3 checkpoints are in the compatibility sections of the user
agent guidelines.  These checkpoints do not exclusively relate to table
access issues, but are needed in Desktop Graphical User Agents for
asssitive technologies to provide efficient access to table element
information.   The following are proposed to be part of the conformance
subset for Desktop Graphical User Agents (IE, Navigator, Opera):

Under Guideline 6.1 "Support language accessibility features" would have
the following checkpoint:
(Note: the word "language" in the guideline name will change to "markup" in
next version of the working draft)

Checkpoint 6.1.4  [Priority 1]
Fully implement the Document Object Model Level 1

Rationale: This provides the information needed by assistive technologies
to access the content of a document for rendering information in a way that
is usable by persons with disabilities, including determining table cell
data and header relationships.

Under Guideline 6.2 "Use and provide accessible interfaces to other
technologies" would have the following checkpoints:

Checkpoint 6.2.6: [Priority 1]
Provide a means for assistive technology to access the user agents Document
Object Model

Rationale:  The document object model must be exposed to assistive
technologies for assistive technology developers to benefit from the user
agent's implementation of the DOM.  This should be done using standard
operating system interfaces that are used and supported for inter-process
communication.

Checkpoint 6.2.7: [Priority 1]
Provide a means for the user to execute a script at the end of loading
(onload event in HTML 4.0 specification) and document changed (may not be
defined in current W3C standards) events.

Rationale: This checkpoint allows the user to improve the rendering of
documents for legacy assistive technologies that are not aware or do not
use contemporary object models or accessibility APIs to directly access the
content of the document for alternative renderings.  For example, scripts
can be developed for legacy screen readers that would allow for table
linearization and the addition of keyboard commands for rudimentary
navigation.  The scripts could be made available by the developers of the
legacy technology or through other public channels.  Scripts could also be
developed for improved compatibility with other types of legacy assistive
technology and to have custom keyboard navigation systems. This checkpoint
is primarily an interim solution to the problem of legacy assistive
technology and to provde custom or "ad hoc" accessibility features that is
not available through assisitve technology.

Checkpoints related to Assistive Technology Conformance for Tables
=================================================================

The following checkpoints are proposed for conformance subset for assistive
technologies for providing access to tables (note the Priority 2 items
would not be required for conformance):

Under Guideline 4.3 "Allow the user to chose formatting solutions" would
have the following checkpoints:

Checkpoint 4.3.1 [Priority 1]
Allow the user to view one table cell at a time with associated header
information

Rationale: Users must have access to the contents of an individual cell and
know what the associated header information is for that cell.  This can be
used by speech, Braille or enlargement assistive technologies.

Checkpoint 4.3.2 [Priority 2]
Allow the user to view one row or one column of a table at a time with
associated header information

Rationale: In some cases rendering a row or column of information is
important for efficiently accessing the information of the document.

Checkpoint 4.3.3 [Priority 1 or 2]
Allow the user to request assumptions be made about table header
information when table header information is not available or is incomplete.

Rationale: This is a table repair technique for poorly written documents
that include tables.

Underline Guideline 5.5 "Allow keyboard navigation of the document and
views of the document" would have the following checkpoints:

Checkpoint 5.5.2 [Priority 1]
Allow users to navigate between cells of a table

Rationale: Basic navigation commands like left/right, up/down and
beginning/end are needed for efficient access to table information.  The
concept of a cell focus (point of regard) would be implied by the
functionality, rather than explicitly stated in the checkpoint.  It is
important since tables are a unique structure within a document.  The
guidelines should highlight the unique navigation that is required for
efficient table element navigation.

Checkpoint 5.5.3 [Priority 1]
Allow users to navigate between structural elements of the document

Rationale: This is a general statement on structural navigation of document
content.  But it relates to tables because it would include the ability to
move between nested tables, since the nesting is a structural component of
the document.

Checkpoint 5.2.7 [Priority 1 or 2] (modification of current checkpoint)
Provide the user with information about the about a table and the current
table cell

Rationale: The user should be able to ask the system at any time about the
summary attribute information, the size of the current table, the
row/column position of the current cell they are viewing in the table and
if the table is embedded in another table.  This can help the user orient
to the document structure and plan their navigation strategy.




Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
University of Illinois at Urbana/Champaign
1207 S. Oak Street
Champaign, IL 61820

Voice: 217-244-5870
Fax: 217-333-0248
E-mail: jongund@uiuc.edu
WWW:	http://www.staff.uiuc.edu/~jongund
	http://www.als.uiuc.edu/InfoTechAccess