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, 16 March 2000 09:24:38 UTC