- From: Jon Gunderson <jongund@staff.uiuc.edu>
- Date: Tue, 02 Feb 1999 10:05:34 -0600
- To: "Denis Anson" <danson@miseri.edu>, <w3c-wai-ua@w3.org>
It is true that the implementation and exposure of DOM to assitive technology does not do anything for accessibility unless assistive technology does something with it. But from the beginning this group has wanted to draw lines over what "mainstream" or desktop graphical browsers need to do and what AT developers will have to work with form the user agent. These checkpoints are that line and it is contained in the compatibility section. The RATIONALE is to provide access to document elements to assistive technology. As long as mainstream browser do this, they have done their part. It is up to assisitve technology vendors to do their part and use the object model to improve functionality. If the group doesn't provide clear directions on this issue, I do not think we will be advancing the accessibility of user agents very much. Jon At 09:08 AM 2/2/99 -0500, Denis Anson wrote: >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 > > 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 Tuesday, 2 February 1999 11:04:47 UTC