- From: Heather Swayne <hswayne@microsoft.com>
- Date: Thu, 6 Apr 2000 09:35:55 -0700
- To: "'w3c-wai-gl@w3.org'" <w3c-wai-gl@w3.org>, WAI AU Guidelines <w3c-wai-au@w3.org>
Issue 1: ok, I can't believe ISVs will stand behind supporting User Agnet DOM and MSAA table support, but the user agents guidelines are outside my realm of influence. Issue 2: other recent discussions on scripting have eliminated this question. Issue 3: thank you for clarifying the logic/need for linearization of tables, however I still feel that we should be working towards a general solution for tables - long-term. Issue 4: After the face-to-face authoring tools working group meeting after CSUN I feel much more comfortable with these particular guidelines. When to prompt, alert, or test for accessibility will continue to be a concern. Heather Swayne Program Manager Microsoft Accessibility and Disabilities Group -----Original Message----- From: Charles McCathieNevile [mailto:charles@w3.org] Sent: Thursday, March 16, 2000 6:25 AM To: Heather Swayne Cc: 'w3c-wai-gl@w3.org' Subject: Re: concerns with the Web Content guidelines Heather, thank you for your comments. My responses are sprinkled in marked CMN. On Wed, 15 Mar 2000, Heather Swayne wrote: The Web Content guidelines 5.1 and 5.2 describe how data tables should be correctly marked up to enable "Future browsers and assistive technologies [to] automatically translate tables into linear sequences or navigate a table cell by cell if data is labeled appropriately." Does this imply that accessibility software vendors will be required to support MSAA (to access information from non HTML applications) and the HTML object model defined by the W3C? CMN The area which determines what should be done by software is the User Agent guidelines. They require that standard platform APIs (in windows this would mean MSAA among others) and W3C DOM are implemented by User Agents (both browsers and assistive technologies) for providing access. HS Web Content guideline 6.3 "Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported..." does not allow for the fact that scripting can be used without creating dynamic client side pages. CMN Can you clarify this comment? As I understand it, you are pointing out that it is possible to do things like client-side validation or processing of forms. In this case it is important to recognise that there are user agents which do not support client-side scripting, and will not be able to use the pages unless thre is some server-side equivalent of the functionality. HS Microsoft Office 2000 made a strong commitment to its users by not requiring IE 5 to be used to view its HTML output. Most Office users live in a mixed browser environment, and cannot rely on users to have the most recent browser. Web Content guidelines 5.3 and 5.4 specifically asked authors to avoiding using tables for layout, regardless of the benefit of using tables for down level browsers and localization (when leveraging automatic text layout within tables). The techniques document section 4.5.2 "Avoid tables for layout" suggests that the user use style sheets for layout, positioning, and all formatting, which would require a level 4 browser or above and additional localization costs. The fact that tables are being so widely used to support down level browsers and to simplify localization efforts, further emphasizes the need for a global text and table solution that does not rely on linearizing tables. CMN THe problem with relying on tables is that there are accessibility solutions inwide use which do not satisfactorily linearise tables into something which preserves the meaning defined by the layout. Therefore, using tables to provide this meaning is an accessibility problem. The WCAG solution is to require that content is made in a form where the semantics do not rely on the layout of the content, but are expressed in the markup. HS I became aware of, and interested in, the Web Content working group because the Authoring Tools guidelines directly point to several Web Content guidelines. I strongly believe that the role of an authoring tool is to make it easier for the user to create great HTML. I define great HTML as accomplishing the users objectives, readable by the users target browser, and of course accessible. The largest difficulty Office, and other HTML authoring tools, will have complying to the WAI's guidelines will be handling users that do not know or care about accessibility. The current Web Content guidelines do not take into account that authoring tools will need to supply most of this information for the author, and without the author's knowledge. Again discussing Web Content guidelines 5.1 and 5.2, it will be impossible to be 100% accurate in guessing what the row and column headers should for all tables, and when an authoring tool guesses wrong we will create a scenario that is worse than having done nothing (the author will feel that their page is accessible, not tool will be able to auto detect the mistake, and the end-user suffers). Both the Web Content and Authoring Tools working groups need to account for an imperfect user. CMN The authoring tool guidelines explicitly state, and implicitly recognise through guideline 6 (about documentation of accessible authoring) and other places, that there are things which cannot be completely automated, and will require the author to do some things - hence the requirement for prompting for alternative content, for example. HS Summary of issues: 1) Web content guidelines, in regards to tables, do not fit with current efforts to address accessibility software vendors' needs for a global (not just HTML) method to access text and tabular information. 2) Web Content guidelines should not condemn scripting just because it could be used to create dynamic content. CMN I do not think the guidelines do this. They simply require that the use of scripting not be relied on (on the client side) and some other method be also provided. HS 3) Web Content guidelines and techniques need to address down level browsers and localization usage of tables. 4) In general, the Web Content guidelines appear to assume an author with perfect knowledge of accessibility. CMN The guidelines do not presume perfect knowledge, but attempt to describe all the requirements which must be met for an author to be confident that they have produced accessible content. HS My objective for writing this alias and participating in any further discussions on this subject is to make you aware of and help you to address the concerns product developers (specifically FrontPage and the rest of Office) will have with your guidelines. If it's appropriate I could attend the WAI Web Content guidelines meeting on March 20th in Los Angeles. CMN Thank you for the comments. THe registration for the meeting has closed, but there will be some discussions which it may be helpful for you to attend - for example the question of what is the bottom line of requirements we can expect from browsers. To attend, you will need to contact Wendy Chisholm - wendy@w3.org - who is the staff contact for the working group. regards Charles McCathieNevile
Received on Thursday, 6 April 2000 12:37:27 UTC