RE: PROPOSAL: Checkpoints related to TABLE accessibility

Jon,

>JRG: Much of the current Microsoft implmentation of DOM is already
exposed.
> By your response it indicates that some parts of DOM are not currently
>accessible be external processes.  Again what we want are the parts that
>are critical for accessibility to be available.

This will be an ongoing process with bridges like MSAA. You never get all
the information you need because it is too much effort to expose all the
information that resides natively. Like MSAA, the Sun Java accessibility
bridge for Windows assistive technologies does have the same limitations.

What these accessibility bridges do is package up what the authors think
people will need and it is often the case that information that could have
been made available is lost to the assistive technology.

The one thing we do need is a very comprehensive accessible DOM interface
that can be supported by browsers while they extend their DOM
implementation to meet their needs.

Rich



Rich Schwerdtfeger
Lead Architect, IBM Special Needs Systems
EMail/web: schwer@us.ibm.com http://www.austin.ibm.com/sns/rich.htm

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost



Jon Gunderson <jongund@staff.uiuc.edu> on 01/28/99 12:47:51 PM

To:   Charles Oppermann <chuckop@microsoft.com>, Kathy Hewitt
      <kathyhe@microsoft.com>, w3c-wai-ua@w3.org
cc:    (bcc: Richard Schwerdtfeger/Austin/IBM)
Subject:  RE: PROPOSAL: Checkpoints related to TABLE accessibility





Response to chuck comments are labeled JRG:

At 10:13 AM 1/28/99 -0800, Charles Oppermann wrote:
>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.
>>>

JRG: I think we can look into this, just as we have for HTML and CSS.  You
are right what we really want implemented are the parts of DOM that
critical for accessibility.

Is this something that you would be willing to write a proposal?

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

JRG: Much of the current Microsoft implmentation of DOM is already exposed.
 By your response it indicates that some parts of DOM are not currently
accessible be external processes.  Again what we want are the parts that
are critical for accessibility to be available.

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

JRG: This was discussed in the telecon yesterday and will be refined.  But
this checkpoint is for Assistive Technology Conformance and would not need
to be provided by the Desktop Graphical User Agent.


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

JRG: Use the first row or first row and column of a table as assumed
headers, even though they may just be TD elements.  It is a repair strategy
for incomplete table markup of header information by the author.

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

Received on Thursday, 28 January 1999 14:11:45 UTC