W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2014

Fwd: Updated testing of Table summary options

From: David MacDonald <david100@sympatico.ca>
Date: Thu, 27 Mar 2014 15:34:25 -0400
Message-ID: <BLU0-SMTP3386F181B3EDAD9C0196C6FE670@phx.gbl>
To: HTML A11Y TF Public <public-html-a11y@w3.org>, Mark Sadecki <mark@w3.org>
I took an action item to update the table summary options.
http://davidmacd.com/test/details.html

I tested with JAWS 15 and NVDA 2014 with Firefox 27 and IE 11 and Google
Chrome 33

===Summary of findings===
The emerging replacement for the table summary appears to be
aria-describedby.

This works in NVDA with Firefox and NVDA with Chrome (but does not work in
JAWS) when the the id is placed on a <p> tag in prose above the table or a
<p> tag inside the <details> tag... like this:

<details>
   <summary>Help</summary>
   <p id="summary2">In the following table Characteristics are given in the
second column, with the negative side in the left column and the positive
side in the right
   column.</p>
</details>
<table aria-describedby="summary2">
  <caption>
    Characteristics with positive and negative sides
  </caption>
  <thead>
    <tr>
      <th id="nnnnnnnn2"> Negative
      <th> Characteristic
      <th> Positive
  <tbody>
        <tr>
          <td headers="nnnnnnnn rrrrrrrr1"> Sad
          <th id="rrrrrrrr3"> Mood
          <td> Happy
    <tr>
            <td headers="nnnnnnnn rrrrrrrr2"> Failing
            <th id="rrrrrrrr4"> Grade
            <td> Passing
</table>

Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy
policy<http://www.davidmacd.com/disclaimer.html>


On Thu, Mar 27, 2014 at 11:05 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>    On Wed, Mar 26, 2014 at 3:55 PM, Rik Cabanier wrote:
>
> >> On Mon, Mar 17, 2014 at 9:10 PM, Jay Munro <jaymunro@microsoft.com>
> wrote:
>
> >> I'd actually recommend just scrapping the ID concept altogether and
> focus on the control nodes.
> >> In fact, add/RemoveHitRegion() could just take a control as the only
> arg. If you want an ID, just
>
> >> use the ID attribute on the control node.
>
> >
>
> > No, it makes sense to create regions without a control.
>
> > For instance, if you draw a dialog with a button on top of other
> controls, you will need to create a region
> > the size of the dialog to obscure the controls at a  lower z-order
>
>
>
> In Monday's meeting, Rich mentioned that the unbacked region is a Level 2
> concept. Is that true? If so, in Level 1 control shouldn't be optional. And
> if control isn't optional, why have a separate ID? You can always just use
> the id attribute of the element.
>
>
>
> Even if control is optional, I wonder if it's worth adding an ID when you
> can always just use the id attribute of the element. The additional benefit
> here being you can scrap the MouseEvent.region extension as well.
>
>
>
> On Wed, Mar 26, 2014 at 3:55 PM, Rik Cabanier wrote:
>
> >> On Mon, Mar 17, 2014 at 9:10 PM, Jay Munro <jaymunro@microsoft.com>
> wrote:
>
> >> *         There doesn't seem to be a way to access the collection of
> added hit regions. I'd expect something
> >> like context.regions to expose a collection of the added regions.
>
> >
>
> > Yes.
>
>
>
> Any thoughts on how you'd like to expose this? We can have a method return
> a list of regions or an attribute that contains the set of regions. Also,
> do we want to provide a method to update those regions or do we expect
> developers to remove and then add a new region.
>
>
>
> On Wed, Mar 26, 2014 at 3:55 PM, Rik Cabanier wrote:
>
> >> On Mon, Mar 17, 2014 at 9:10 PM, Jay Munro <jaymunro@microsoft.com>
> wrote:
>
> >> o   E.g. it currently seems I have to remove and add a hit region if I
> just want to update it.
> >> Perhaps it's felt this isn't needed in an immediate-mode graphics API?
> >> *         Spec should also handle PointerEvents too!
>
> >
>
> > I think event handling is underspecified.
>
>
>
> I think we should support PointerEvents as well. The event handling
> section does need more work.
>
Received on Thursday, 27 March 2014 19:34:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:38 UTC