RE: [techs] Table Summary Tests (111, 112, 113, 114, 203)

Is anyone actively raising issues with Freedom Scientific? Is there
Freedom Scientific rep on WCAG? 

It seems pretty cavalier to just assume you will be able to deliver a
list of issues to them at the end of this process. The result is not
likely to be that JAWS and content work better together. 

There is a spirit of collaboration missing. Did anyone look into the
thinking that went into that change? Was it deliberate or an oversight?
Is it easy for them to make a change or should the guidelines reflect
what is possible today? 

You leap right to a conclusion here that, as a vendor, frightens me. It
is easy for Roberto to make blanket assumptions about what is right,
broken and illogical. However, such assumptions are not likely to
consistently produce the outcomes we are looking for. 


bob regan | macromedia | 415.832.5305

-----Original Message-----
From: [] On
Behalf Of Roberto Scano (IWA/HWG)
Sent: Wednesday, August 17, 2005 11:07 PM
Subject: RE: [techs] Table Summary Tests (111, 112, 113, 114, 203)

We need to develop wcag that are for *all* disabilities, and not be
vendor-specific. If it's a Jaws problem, ask to fix it to them, and not
that w3c should fix wcag guidelines.
(as for valid code...)
----- Messaggio originale -----
    Da: "Mirabella, Mathew J"<>
    Inviato: 18/08/05 4.40.34
    A: "w3c-wai-gl list"<>
    Oggetto: [techs] Table Summary Tests (111, 112, 113, 114, 203)
    >> but with JAWS the user can jump directly to any table on the page
    >> pressing the letter "t".  If the table has a <caption> element,
    >> speaks the caption; it will also speak the summary if it's
    >> Pressing the "t" would cause JAWS to bypass the H<x> element in
    >> example above.
    > Thank you for documenting another way in which Jaws is a broken
    > agent. I'm sure the Working Group will custom-craft its techniques
    > accommodate exactly what Jaws does in this instance.
    I agree that Jaws is far from perfect, especially considering that
    every so called improved new version of this same program seems
    to change the way it behaves with web content, and as such causes
    problems, for 
    Real people etc.
    However, in an example where you have an hx element above a table,
    a caption
    in a table, What is inherently wrong with Jaws doing something like
    moving to the
    table (thus skipping the hx) when the user presses t?  h/shift-h in
    Between the headings, t/shift-t moves between the tables.  Why
    jaws consider
    An hx to be any part of the table just because it appears above the
    For all we know, the hx could be a section heading in the page that
    happens to be
    followed by a table.
    If we want to suggest that an hx just above a table is suficient to
    actually link  that
    Table to that hx as explicitly as, for example, label with form
    then we are
    starting to expect user agents and assistive technologies to make
    decision about the linkages
    Between different things on a page due to nothing more than screen
    code proximity.  I hope
    People can see the problems inherent in this.
    So how can you link a table to a header that is above it... Is there
    for/id linkage that can be
    made?  No... So my example shows the inclusion of an hx inside the
    caption.... Which is not
    Given just for jaws compatibility, but because it seems to be a
    way to resolve
    The linkage issue in an explicit way in the code... Which is what we
    So in the example where the hx is above the table with caption, Jaws
    probably not really
    Doing the wrong thing.  That's not to say that Jaws never does the
    thing by the way.

[Messaggio troncato. Toccare Modifica->Segna per il download per
recuperare la restante parte.]

Received on Thursday, 18 August 2005 14:19:08 UTC