E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 32 (In chronological order)

From: Steve Flaukner
Date: Thu, Feb 09 2012 1:30PM
Subject: Using Tables
No previous message | Next message →

Is a summary a must for a screen reader or will the caption be good enough?
Assumming the table is classified as complex.

From: Ted
Date: Fri, Feb 10 2012 12:24PM
Subject: Re: Using Tables
← Previous message | Next message →

Definitely need a summary for complex tables. Makes it much easier to pick
out the purpose, overall structure, trends in the data etc.

Ted Page
PWS Ltd

From: Jared Smith
Date: Fri, Feb 10 2012 5:24PM
Subject: Re: Using Tables
← Previous message | Next message →

On Fri, Feb 10, 2012 at 12:23 PM, Ted wrote:
> Definitely need a summary for complex tables.

I disagree. A few reasons why I think summary is almost universally a bad idea:

1. If the table is so complex that its structure needs to be explained
to the user, it's too complex. Period.

2. Summary is screen-reader only and is forced upon the screen reader
user each time the table is encountered. With proper table markup, the
user should be able to quickly navigate the table to determine its
content and structure, in the same way that sighted users must scan a
table to determine its content and structure.

3. Summary is currently not part of HTML5.

4. Summary is NOT for presenting the purpose or content of the table.
It's for describing its structure, when necessary (see #1). Probably
90% of summary attributes on the web get this wrong. If it's important
that the purpose or content of the table be presented, this should be
done in a way that is accessible to everyone (e.g., <caption>, etc.).

It's a rarity to find a summary attribute that does much good. They
are almost always a waste of time or an excuse for presenting an
overly complex table. Or both.

And no, I don't have strong feeling on the subject. :-)

Jared

From: Ryan E. Benson
Date: Fri, Feb 10 2012 8:57PM
Subject: Re: Using Tables
← Previous message | Next message →

> 4. Summary is NOT for presenting the purpose or content of the table.
> It's for describing its structure, when necessary (see #1).
What makes you say that Jared? The spec (html 4) says the exact opposite
"summary = text [CS]
This attribute provides a summary of the table's purpose and structure
for user agents rendering to non-visual media such as speech and
Braille." - http://www.w3.org/TR/html4/struct/tables.html#adef-summary

--
Ryan E. Benson



On Fri, Feb 10, 2012 at 7:25 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Fri, Feb 10, 2012 at 12:23 PM, Ted wrote:
>> Definitely need a summary for complex tables.
>
> I disagree. A few reasons why I think summary is almost universally a bad idea:
>
> 1. If the table is so complex that its structure needs to be explained
> to the user, it's too complex. Period.
>
> 2. Summary is screen-reader only and is forced upon the screen reader
> user each time the table is encountered. With proper table markup, the
> user should be able to quickly navigate the table to determine its
> content and structure, in the same way that sighted users must scan a
> table to determine its content and structure.
>
> 3. Summary is currently not part of HTML5.
>
> 4. Summary is NOT for presenting the purpose or content of the table.
> It's for describing its structure, when necessary (see #1). Probably
> 90% of summary attributes on the web get this wrong. If it's important
> that the purpose or content of the table be presented, this should be
> done in a way that is accessible to everyone (e.g., <caption>, etc.).
>
> It's a rarity to find a summary attribute that does much good. They
> are almost always a waste of time or an excuse for presenting an
> overly complex table. Or both.
>
> And no, I don't have strong feeling on the subject. :-)
>
> Jared
>

From: Jared Smith
Date: Fri, Feb 10 2012 9:36PM
Subject: Re: Using Tables
← Previous message | Next message →

On Fri, Feb 10, 2012 at 9:00 PM, Ryan E. Benson wrote:
> What makes you say that Jared? The spec (html 4) says the exact opposite

I guess I misunderstood this, probably because when summary was still
in HTML5 it was defined as for structure only. Still, it doesn't make
much sense to me to present the purpose to screen reader users only.

My point is that if a table is natively clear and accessible,
providing a summary won't make it more accessible. And if it's not
natively accessible, then it needs to be made accessible.

Jared

From: Ryan E. Benson
Date: Fri, Feb 10 2012 10:09PM
Subject: Re: Using Tables
← Previous message | Next message →

I have ignored what HTML 5 says for the most part cause it isn't done,
and kind of chuckle at it. I think people who are using it and writing
books about it are doing it prematurely.

> Still, it doesn't make much sense to me to
> present the purpose to screen reader users only.
The flip side is why do screen readers allow you to jump between
tables? I think until you can tie a visual element (thinking a heading
here) to a table a summary is needed. Summaries are usually required
for where I work due to their nature, and couldn't really be broken
down effectively.

--
Ryan E. Benson



On Fri, Feb 10, 2012 at 11:37 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Fri, Feb 10, 2012 at 9:00 PM, Ryan E. Benson wrote:
>> What makes you say that Jared? The spec (html 4) says the exact opposite
>
> I guess I misunderstood this, probably because when summary was still
> in HTML5 it was defined as for structure only. Still, it doesn't make
> much sense to me to present the purpose to screen reader users only.
>
> My point is that if a table is natively clear and accessible,
> providing a summary won't make it more accessible. And if it's not
> natively accessible, then it needs to be made accessible.
>
> Jared
>

From: Steve Faulkner
Date: Sat, Feb 11 2012 2:12AM
Subject: Re: Using Tables
← Previous message | Next message →

Hi Ryan,
"I have ignored what HTML 5 says for the most part cause it isn't done,
and kind of chuckle at it. I think people who are using it and writing
books about it are doing it prematurely."

many aspects of HTML5 are here right now and being used so it makes sense
take it into account.Part of the accessibility support problem is/has been
that what is in specs and what is supported are not always the same thing.
As accessibility practitioners we need to be mindful of this and provide
best practise advice based on implementation realities.

best regards
Stevef

The summary attribute is not and has never been well supported across
browsers and AT, so using it to provide important information, means it is
not available to some users who would benefit from the information.



On 11 February 2012 05:07, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:

> I have ignored what HTML 5 says for the most part cause it isn't done,
> and kind of chuckle at it. I think people who are using it and writing
> books about it are doing it prematurely.
>
> > Still, it doesn't make much sense to me to
> > present the purpose to screen reader users only.
> The flip side is why do screen readers allow you to jump between
> tables? I think until you can tie a visual element (thinking a heading
> here) to a table a summary is needed. Summaries are usually required
> for where I work due to their nature, and couldn't really be broken
> down effectively.
>
> --
> Ryan E. Benson
>
>
>
> On Fri, Feb 10, 2012 at 11:37 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> > On Fri, Feb 10, 2012 at 9:00 PM, Ryan E. Benson wrote:
> >> What makes you say that Jared? The spec (html 4) says the exact opposite
> >
> > I guess I misunderstood this, probably because when summary was still
> > in HTML5 it was defined as for structure only. Still, it doesn't make
> > much sense to me to present the purpose to screen reader users only.
> >
> > My point is that if a table is natively clear and accessible,
> > providing a summary won't make it more accessible. And if it's not
> > natively accessible, then it needs to be made accessible.
> >
> > Jared
> >

From: Benjamin Hawkes-Lewis
Date: Sat, Feb 11 2012 5:48AM
Subject: Re: Using Tables
← Previous message | Next message →

On Sat, Feb 11, 2012 at 5:07 AM, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
> I think until you can tie a visual element (thinking a heading
> here) to a table a summary is needed.

The <caption> element (for text inside the table) or the attributes
@aria-labelledby and @aria-describedby (for text outside the table)
can do that.

--
Benjamin Hawkes-Lewis

From: Benjamin Hawkes-Lewis
Date: Sat, Feb 11 2012 5:54AM
Subject: Re: Using Tables
← Previous message | Next message →

On Sat, Feb 11, 2012 at 12:51 PM, Benjamin Hawkes-Lewis
< = EMAIL ADDRESS REMOVED = > wrote:
> On Sat, Feb 11, 2012 at 5:07 AM, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
>> I think until you can tie a visual element (thinking a heading
>> here) to a table a summary is needed.
>
> The <caption> element (for text inside the table) or the attributes
> @aria-labelledby and @aria-describedby (for text outside the table)
> can do that.

There should also really be implicit associations between headings and
<figcaption> elements preceding the table in the absence of more
explicit markup, but I don't think that's been specified
unfortunately.

--
Benjamin Hawkes-Lewis

From: Ryan E. Benson
Date: Sat, Feb 11 2012 5:57PM
Subject: Re: Using Tables
← Previous message | Next message →

Steve,
> many aspects of HTML5 are here right now and being used so it makes sense
> take it into account.Part of the accessibility support problem is/has been
> that what is in specs and what is supported are not always the same thing.
> As accessibility practitioners we need to be mindful of this and provide
> best practise advice based on implementation realities.
Jumping on the band wagon before HTML5 is even a PR is just a little
preemptive for me. At work we are still on IE8, even boxes running
Win7, so doing HTML5 for example, is just a waste of time for now.
--
Ryan E. Benson



On Sat, Feb 11, 2012 at 4:14 AM, Steve Faulkner
< = EMAIL ADDRESS REMOVED = > wrote:
> Hi Ryan,
>  "I have ignored what HTML 5 says for the most part cause it isn't done,
> and kind of chuckle at it. I think people who are using it and writing
> books about it are doing it prematurely."
>
> many aspects of HTML5 are here right now and being used so it makes sense
> take it into account.Part of the accessibility support problem is/has been
> that what is in specs and what is supported are not always the same thing.
> As accessibility practitioners we need to be mindful of this and provide
> best practise advice based on implementation realities.
>
> best regards
> Stevef
>
> The summary attribute is not and has never been well supported across
> browsers and AT, so using it to provide important information, means it is
> not available to some users who would benefit from the information.
>
>
>
> On 11 February 2012 05:07, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I have ignored what HTML 5 says for the most part cause it isn't done,
>> and kind of chuckle at it. I think people who are using it and writing
>> books about it are doing it prematurely.
>>
>> > Still, it doesn't make much sense to me to
>> > present the purpose to screen reader users only.
>> The flip side is why do screen readers allow you to jump between
>> tables? I think until you can tie a visual element (thinking a heading
>> here) to a table a summary is needed. Summaries are usually required
>> for where I work due to their nature, and couldn't really be broken
>> down effectively.
>>
>> --
>> Ryan E. Benson
>>
>>
>>
>> On Fri, Feb 10, 2012 at 11:37 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>> > On Fri, Feb 10, 2012 at 9:00 PM, Ryan E. Benson wrote:
>> >> What makes you say that Jared? The spec (html 4) says the exact opposite
>> >
>> > I guess I misunderstood this, probably because when summary was still
>> > in HTML5 it was defined as for structure only. Still, it doesn't make
>> > much sense to me to present the purpose to screen reader users only.
>> >
>> > My point is that if a table is natively clear and accessible,
>> > providing a summary won't make it more accessible. And if it's not
>> > natively accessible, then it needs to be made accessible.
>> >
>> > Jared
>> >

From: Vincent Young
Date: Sat, Feb 11 2012 6:54PM
Subject: Re: Using Tables
← Previous message | Next message →

> Jumping on the band wagon before HTML5 is even a PR is just a little
> preemptive for me. At work we are still on IE8, even boxes running
> Win7, so doing HTML5 for example, is just a waste of time for now.

Even if running on older systems, incorporating most HTML5 into your work
now probably does more good than harm. Doing so is fairly easy with
solutions such as html5shiv (http://code.google.com/p/html5shiv/). When
you're ready to upgrade your systems, no hassle and users can begin to use
the HTML5 elements that are being exposed by AT. I guess it all depends on
the environment, so your reasoning makes sense. For me, HTML5 is just too
fun to wait!

On Sat, Feb 11, 2012 at 4:58 PM, Ryan E. Benson < = EMAIL ADDRESS REMOVED = >wrote:

> Steve,
> > many aspects of HTML5 are here right now and being used so it makes sense
> > take it into account.Part of the accessibility support problem is/has
> been
> > that what is in specs and what is supported are not always the same
> thing.
> > As accessibility practitioners we need to be mindful of this and provide
> > best practise advice based on implementation realities.
> Jumping on the band wagon before HTML5 is even a PR is just a little
> preemptive for me. At work we are still on IE8, even boxes running
> Win7, so doing HTML5 for example, is just a waste of time for now.
> --
> Ryan E. Benson
>
>
>
> On Sat, Feb 11, 2012 at 4:14 AM, Steve Faulkner
> < = EMAIL ADDRESS REMOVED = > wrote:
> > Hi Ryan,
> > "I have ignored what HTML 5 says for the most part cause it isn't done,
> > and kind of chuckle at it. I think people who are using it and writing
> > books about it are doing it prematurely."
> >
> > many aspects of HTML5 are here right now and being used so it makes sense
> > take it into account.Part of the accessibility support problem is/has
> been
> > that what is in specs and what is supported are not always the same
> thing.
> > As accessibility practitioners we need to be mindful of this and provide
> > best practise advice based on implementation realities.
> >
> > best regards
> > Stevef
> >
> > The summary attribute is not and has never been well supported across
> > browsers and AT, so using it to provide important information, means it
> is
> > not available to some users who would benefit from the information.
> >
> >
> >
> > On 11 February 2012 05:07, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> I have ignored what HTML 5 says for the most part cause it isn't done,
> >> and kind of chuckle at it. I think people who are using it and writing
> >> books about it are doing it prematurely.
> >>
> >> > Still, it doesn't make much sense to me to
> >> > present the purpose to screen reader users only.
> >> The flip side is why do screen readers allow you to jump between
> >> tables? I think until you can tie a visual element (thinking a heading
> >> here) to a table a summary is needed. Summaries are usually required
> >> for where I work due to their nature, and couldn't really be broken
> >> down effectively.
> >>
> >> --
> >> Ryan E. Benson
> >>
> >>
> >>
> >> On Fri, Feb 10, 2012 at 11:37 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> >> > On Fri, Feb 10, 2012 at 9:00 PM, Ryan E. Benson wrote:
> >> >> What makes you say that Jared? The spec (html 4) says the exact
> opposite
> >> >
> >> > I guess I misunderstood this, probably because when summary was still
> >> > in HTML5 it was defined as for structure only. Still, it doesn't make
> >> > much sense to me to present the purpose to screen reader users only.
> >> >
> >> > My point is that if a table is natively clear and accessible,
> >> > providing a summary won't make it more accessible. And if it's not
> >> > natively accessible, then it needs to be made accessible.
> >> >
> >> > Jared
> >> >

From: Ryan E. Benson
Date: Sat, Feb 11 2012 8:30PM
Subject: Re: Using Tables
← Previous message | Next message →

> Doing so is fairly easy with solutions such as html5shiv (http://code.google.com/p/html5shiv/).
Only problem with that is, more stuff to load. Pages often load tons
of scripts to make this little ajax box or whatever, loading a script
to get super cool features is again, a waste.

> the HTML5 elements that are being exposed by AT.  I guess it all depends on
> the environment, so your reasoning makes sense.  For me, HTML5 is just too
> fun to wait!
Check out Steve's work at http://html5accessibility.com/, far too many
html5 "features" have the not supported or not implemented mark to use
them, which is some of my reasoning as to why I say HTML5 is not
mature enough. If you say if we use them browsers will have to make
them work. Ok, while not the direct same, Google still has issues with
accessibility on all of their products and cannot produce valid code,
yet it has employees on almost all W3C WG.

--
Ryan E. Benson



On Sat, Feb 11, 2012 at 8:55 PM, Vincent Young < = EMAIL ADDRESS REMOVED = > wrote:
>> Jumping on the band wagon before HTML5 is even a PR is just a little
>> preemptive for me. At work we are still on IE8, even boxes running
>> Win7, so doing HTML5 for example, is just a waste of time for now.
>
> Even if running on older systems, incorporating most HTML5 into your work
> now probably does more good than harm.  Doing so is fairly easy with
> solutions such as html5shiv (http://code.google.com/p/html5shiv/).  When
> you're ready to upgrade your systems, no hassle and users can begin to use
> the HTML5 elements that are being exposed by AT.  I guess it all depends on
> the environment, so your reasoning makes sense.  For me, HTML5 is just too
> fun to wait!
>
> On Sat, Feb 11, 2012 at 4:58 PM, Ryan E. Benson < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Steve,
>> > many aspects of HTML5 are here right now and being used so it makes sense
>> > take it into account.Part of the accessibility support problem is/has
>> been
>> > that what is in specs and what is supported are not always the same
>> thing.
>> > As accessibility practitioners we need to be mindful of this and provide
>> > best practise advice based on implementation realities.
>> Jumping on the band wagon before HTML5 is even a PR is just a little
>> preemptive for me. At work we are still on IE8, even boxes running
>> Win7, so doing HTML5 for example, is just a waste of time for now.
>> --
>> Ryan E. Benson
>>
>>
>>
>> On Sat, Feb 11, 2012 at 4:14 AM, Steve Faulkner
>> < = EMAIL ADDRESS REMOVED = > wrote:
>> > Hi Ryan,
>> >  "I have ignored what HTML 5 says for the most part cause it isn't done,
>> > and kind of chuckle at it. I think people who are using it and writing
>> > books about it are doing it prematurely."
>> >
>> > many aspects of HTML5 are here right now and being used so it makes sense
>> > take it into account.Part of the accessibility support problem is/has
>> been
>> > that what is in specs and what is supported are not always the same
>> thing.
>> > As accessibility practitioners we need to be mindful of this and provide
>> > best practise advice based on implementation realities.
>> >
>> > best regards
>> > Stevef
>> >
>> > The summary attribute is not and has never been well supported across
>> > browsers and AT, so using it to provide important information, means it
>> is
>> > not available to some users who would benefit from the information.
>> >
>> >
>> >
>> > On 11 February 2012 05:07, Ryan E. Benson < = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> >> I have ignored what HTML 5 says for the most part cause it isn't done,
>> >> and kind of chuckle at it. I think people who are using it and writing
>> >> books about it are doing it prematurely.
>> >>
>> >> > Still, it doesn't make much sense to me to
>> >> > present the purpose to screen reader users only.
>> >> The flip side is why do screen readers allow you to jump between
>> >> tables? I think until you can tie a visual element (thinking a heading
>> >> here) to a table a summary is needed. Summaries are usually required
>> >> for where I work due to their nature, and couldn't really be broken
>> >> down effectively.
>> >>
>> >> --
>> >> Ryan E. Benson
>> >>
>> >>
>> >>
>> >> On Fri, Feb 10, 2012 at 11:37 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>> >> > On Fri, Feb 10, 2012 at 9:00 PM, Ryan E. Benson wrote:
>> >> >> What makes you say that Jared? The spec (html 4) says the exact
>> opposite
>> >> >
>> >> > I guess I misunderstood this, probably because when summary was still
>> >> > in HTML5 it was defined as for structure only. Still, it doesn't make
>> >> > much sense to me to present the purpose to screen reader users only.
>> >> >
>> >> > My point is that if a table is natively clear and accessible,
>> >> > providing a summary won't make it more accessible. And if it's not
>> >> > natively accessible, then it needs to be made accessible.
>> >> >
>> >> > Jared
>> >> >

From: Vincent Young
Date: Sat, Feb 11 2012 9:12PM
Subject: Re: Using Tables
← Previous message | Next message →

> loading a script to get super cool features is again, a waste.

Fair enough, but don't agree. With my work, it depends on the
situation/project. The file is 3,335 bytes that are included in my library
JavaScript file. The amount of download and rendering time in IE8 and
below typically have not made enough of a difference.

> Check out Steve's work at http://html5accessibility.com/ far too many
html5 "features" have the not supported or not implemented mark to use them

I had seen this article and it's a good read, but for me, it's all the more
reason to continue to try and use these elements. We'll just write this
off as a difference in ideology about incorporating things on the web that
have not made it into the W3C PR. I will of course encourage as many
developers to continue to use and push HTML5. I think the web will become
better as a result.


On Sat, Feb 11, 2012 at 7:31 PM, Ryan E. Benson < = EMAIL ADDRESS REMOVED = >wrote:

> > Doing so is fairly easy with solutions such as html5shiv (
> http://code.google.com/p/html5shiv/).
> Only problem with that is, more stuff to load. Pages often load tons
> of scripts to make this little ajax box or whatever, loading a script
> to get super cool features is again, a waste.
>
> > the HTML5 elements that are being exposed by AT. I guess it all depends
> on
> > the environment, so your reasoning makes sense. For me, HTML5 is just
> too
> > fun to wait!
> Check out Steve's work at http://html5accessibility.com/, far too many
> html5 "features" have the not supported or not implemented mark to use
> them, which is some of my reasoning as to why I say HTML5 is not
> mature enough. If you say if we use them browsers will have to make
> them work. Ok, while not the direct same, Google still has issues with
> accessibility on all of their products and cannot produce valid code,
> yet it has employees on almost all W3C WG.
>
> --
> Ryan E. Benson
>
>
>
> On Sat, Feb 11, 2012 at 8:55 PM, Vincent Young < = EMAIL ADDRESS REMOVED = >
> wrote:
> >> Jumping on the band wagon before HTML5 is even a PR is just a little
> >> preemptive for me. At work we are still on IE8, even boxes running
> >> Win7, so doing HTML5 for example, is just a waste of time for now.
> >
> > Even if running on older systems, incorporating most HTML5 into your work
> > now probably does more good than harm. Doing so is fairly easy with
> > solutions such as html5shiv (http://code.google.com/p/html5shiv/). When
> > you're ready to upgrade your systems, no hassle and users can begin to
> use
> > the HTML5 elements that are being exposed by AT. I guess it all depends
> on
> > the environment, so your reasoning makes sense. For me, HTML5 is just
> too
> > fun to wait!
> >
> > On Sat, Feb 11, 2012 at 4:58 PM, Ryan E. Benson < = EMAIL ADDRESS REMOVED =
> >wrote:
> >
> >> Steve,
> >> > many aspects of HTML5 are here right now and being used so it makes
> sense
> >> > take it into account.Part of the accessibility support problem is/has
> >> been
> >> > that what is in specs and what is supported are not always the same
> >> thing.
> >> > As accessibility practitioners we need to be mindful of this and
> provide
> >> > best practise advice based on implementation realities.
> >> Jumping on the band wagon before HTML5 is even a PR is just a little
> >> preemptive for me. At work we are still on IE8, even boxes running
> >> Win7, so doing HTML5 for example, is just a waste of time for now.
> >> --
> >> Ryan E. Benson
> >>
> >>
> >>
> >> On Sat, Feb 11, 2012 at 4:14 AM, Steve Faulkner
> >> < = EMAIL ADDRESS REMOVED = > wrote:
> >> > Hi Ryan,
> >> > "I have ignored what HTML 5 says for the most part cause it isn't
> done,
> >> > and kind of chuckle at it. I think people who are using it and writing
> >> > books about it are doing it prematurely."
> >> >
> >> > many aspects of HTML5 are here right now and being used so it makes
> sense
> >> > take it into account.Part of the accessibility support problem is/has
> >> been
> >> > that what is in specs and what is supported are not always the same
> >> thing.
> >> > As accessibility practitioners we need to be mindful of this and
> provide
> >> > best practise advice based on implementation realities.
> >> >
> >> > best regards
> >> > Stevef
> >> >
> >> > The summary attribute is not and has never been well supported across
> >> > browsers and AT, so using it to provide important information, means
> it
> >> is
> >> > not available to some users who would benefit from the information.
> >> >
> >> >
> >> >
> >> > On 11 February 2012 05:07, Ryan E. Benson < = EMAIL ADDRESS REMOVED = >
> wrote:
> >> >
> >> >> I have ignored what HTML 5 says for the most part cause it isn't
> done,
> >> >> and kind of chuckle at it. I think people who are using it and
> writing
> >> >> books about it are doing it prematurely.
> >> >>
> >> >> > Still, it doesn't make much sense to me to
> >> >> > present the purpose to screen reader users only.
> >> >> The flip side is why do screen readers allow you to jump between
> >> >> tables? I think until you can tie a visual element (thinking a
> heading
> >> >> here) to a table a summary is needed. Summaries are usually required
> >> >> for where I work due to their nature, and couldn't really be broken
> >> >> down effectively.
> >> >>
> >> >> --
> >> >> Ryan E. Benson
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Feb 10, 2012 at 11:37 PM, Jared Smith < = EMAIL ADDRESS REMOVED = >
> wrote:
> >> >> > On Fri, Feb 10, 2012 at 9:00 PM, Ryan E. Benson wrote:
> >> >> >> What makes you say that Jared? The spec (html 4) says the exact
> >> opposite
> >> >> >
> >> >> > I guess I misunderstood this, probably because when summary was
> still
> >> >> > in HTML5 it was defined as for structure only. Still, it doesn't
> make
> >> >> > much sense to me to present the purpose to screen reader users
> only.
> >> >> >
> >> >> > My point is that if a table is natively clear and accessible,
> >> >> > providing a summary won't make it more accessible. And if it's not
> >> >> > natively accessible, then it needs to be made accessible.
> >> >> >
> >> >> > Jared
> >> >> >

From: Ryan E. Benson
Date: Sun, Feb 12 2012 12:21AM
Subject: Re: Using Tables
← Previous message | Next message →

> I think the web will become better as a result.
I will direct your attention to IE6+, and the lovely bugs it caused.
By 2001, MS knew of this thing called web standards, it chose to not
play by the rules. The old timers could probably tell you how long it
took to figure out IE6 didn't play nice. I am sure various people were
knocking on their door to get stuff together, it took another 5 years
to get another attempt out. Why hack something, instead of knowing it
isn't go time yet.

--
Ryan E. Benson



On Sat, Feb 11, 2012 at 11:14 PM, Vincent Young < = EMAIL ADDRESS REMOVED = > wrote:
>> loading a script to get super cool features is again, a waste.
>
> Fair enough, but don't agree.  With my work, it depends on the
> situation/project.  The file is 3,335 bytes that are included in my library
> JavaScript file.  The amount of download and rendering time in IE8 and
> below typically have not made enough of a difference.
>
>> Check out Steve's work at http://html5accessibility.com/ far too many
> html5 "features" have the not supported or not implemented mark to use them
>
> I had seen this article and it's a good read, but for me, it's all the more
> reason to continue to try and use these elements.  We'll just write this
> off as a difference in ideology about incorporating things on the web that
> have not made it into the W3C PR.  I will of course encourage as many
> developers to continue to use and push HTML5.  I think the web will become
> better as a result.
>
>
> On Sat, Feb 11, 2012 at 7:31 PM, Ryan E. Benson < = EMAIL ADDRESS REMOVED = >wrote:
>
>> > Doing so is fairly easy with solutions such as html5shiv (
>> http://code.google.com/p/html5shiv/).
>> Only problem with that is, more stuff to load. Pages often load tons
>> of scripts to make this little ajax box or whatever, loading a script
>> to get super cool features is again, a waste.
>>
>> > the HTML5 elements that are being exposed by AT.  I guess it all depends
>> on
>> > the environment, so your reasoning makes sense.  For me, HTML5 is just
>> too
>> > fun to wait!
>> Check out Steve's work at http://html5accessibility.com/, far too many
>> html5 "features" have the not supported or not implemented mark to use
>> them, which is some of my reasoning as to why I say HTML5 is not
>> mature enough. If you say if we use them browsers will have to make
>> them work. Ok, while not the direct same, Google still has issues with
>> accessibility on all of their products and cannot produce valid code,
>> yet it has employees on almost all W3C WG.
>>
>> --
>> Ryan E. Benson
>>
>>
>>
>> On Sat, Feb 11, 2012 at 8:55 PM, Vincent Young < = EMAIL ADDRESS REMOVED = >
>> wrote:
>> >> Jumping on the band wagon before HTML5 is even a PR is just a little
>> >> preemptive for me. At work we are still on IE8, even boxes running
>> >> Win7, so doing HTML5 for example, is just a waste of time for now.
>> >
>> > Even if running on older systems, incorporating most HTML5 into your work
>> > now probably does more good than harm.  Doing so is fairly easy with
>> > solutions such as html5shiv (http://code.google.com/p/html5shiv/).  When
>> > you're ready to upgrade your systems, no hassle and users can begin to
>> use
>> > the HTML5 elements that are being exposed by AT.  I guess it all depends
>> on
>> > the environment, so your reasoning makes sense.  For me, HTML5 is just
>> too
>> > fun to wait!
>> >
>> > On Sat, Feb 11, 2012 at 4:58 PM, Ryan E. Benson < = EMAIL ADDRESS REMOVED =
>> >wrote:
>> >
>> >> Steve,
>> >> > many aspects of HTML5 are here right now and being used so it makes
>> sense
>> >> > take it into account.Part of the accessibility support problem is/has
>> >> been
>> >> > that what is in specs and what is supported are not always the same
>> >> thing.
>> >> > As accessibility practitioners we need to be mindful of this and
>> provide
>> >> > best practise advice based on implementation realities.
>> >> Jumping on the band wagon before HTML5 is even a PR is just a little
>> >> preemptive for me. At work we are still on IE8, even boxes running
>> >> Win7, so doing HTML5 for example, is just a waste of time for now.
>> >> --
>> >> Ryan E. Benson
>> >>
>> >>
>> >>
>> >> On Sat, Feb 11, 2012 at 4:14 AM, Steve Faulkner
>> >> < = EMAIL ADDRESS REMOVED = > wrote:
>> >> > Hi Ryan,
>> >> >  "I have ignored what HTML 5 says for the most part cause it isn't
>> done,
>> >> > and kind of chuckle at it. I think people who are using it and writing
>> >> > books about it are doing it prematurely."
>> >> >
>> >> > many aspects of HTML5 are here right now and being used so it makes
>> sense
>> >> > take it into account.Part of the accessibility support problem is/has
>> >> been
>> >> > that what is in specs and what is supported are not always the same
>> >> thing.
>> >> > As accessibility practitioners we need to be mindful of this and
>> provide
>> >> > best practise advice based on implementation realities.
>> >> >
>> >> > best regards
>> >> > Stevef
>> >> >
>> >> > The summary attribute is not and has never been well supported across
>> >> > browsers and AT, so using it to provide important information, means
>> it
>> >> is
>> >> > not available to some users who would benefit from the information.
>> >> >
>> >> >
>> >> >
>> >> > On 11 February 2012 05:07, Ryan E. Benson < = EMAIL ADDRESS REMOVED = >
>> wrote:
>> >> >
>> >> >> I have ignored what HTML 5 says for the most part cause it isn't
>> done,
>> >> >> and kind of chuckle at it. I think people who are using it and
>> writing
>> >> >> books about it are doing it prematurely.
>> >> >>
>> >> >> > Still, it doesn't make much sense to me to
>> >> >> > present the purpose to screen reader users only.
>> >> >> The flip side is why do screen readers allow you to jump between
>> >> >> tables? I think until you can tie a visual element (thinking a
>> heading
>> >> >> here) to a table a summary is needed. Summaries are usually required
>> >> >> for where I work due to their nature, and couldn't really be broken
>> >> >> down effectively.
>> >> >>
>> >> >> --
>> >> >> Ryan E. Benson
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Fri, Feb 10, 2012 at 11:37 PM, Jared Smith < = EMAIL ADDRESS REMOVED = >
>> wrote:
>> >> >> > On Fri, Feb 10, 2012 at 9:00 PM, Ryan E. Benson wrote:
>> >> >> >> What makes you say that Jared? The spec (html 4) says the exact
>> >> opposite
>> >> >> >
>> >> >> > I guess I misunderstood this, probably because when summary was
>> still
>> >> >> > in HTML5 it was defined as for structure only. Still, it doesn't
>> make
>> >> >> > much sense to me to present the purpose to screen reader users
>> only.
>> >> >> >
>> >> >> > My point is that if a table is natively clear and accessible,
>> >> >> > providing a summary won't make it more accessible. And if it's not
>> >> >> > natively accessible, then it needs to be made accessible.
>> >> >> >
>> >> >> > Jared
>> >> >> >

From: Ted
Date: Sun, Feb 12 2012 12:03PM
Subject: Re: Using Tables
← Previous message | Next message →

The HTML5 spec doesn't include a summary attribute: instead it recommends
adding summary information in the main body of a document for all to see.

Authors are advised to add summaries for complex tables, and specifically
that they might describe trends and patterns in the data, how it's sorted
etc, as well as the structure of the table.

As this kind of information is often obvious to sighted readers but can take
a lot of time and effort to get a feel for if you can only read a table in a
linear manner as with a screen reader, I think there is a strong case for
retaining the summary attribute. However, in other cases I can see that a
well constructed summary could be useful to all readers.

As you can probably tell, I'm a strong advocate of table summaries. Just
because they are often poorly authored isn't a reason not to use them - it's
an argument for teaching people how to write them properly.

Ted Page
Director, PWS Ltd

From: Randy Pope
Date: Sun, Feb 12 2012 6:18PM
Subject: Re: Using Tables
← Previous message | Next message →

From most of the feedbacks of those (mostly deaf-blind people) who read in
braille, the table summary tends to be more of a nuisance than help. The
complaints was too much information or reading, or not needed when the table
is properly structure that can be clearly understood. As for the those who
use voice to read the web, I'm not sure what their thoughts are.

With Warm Regards,
Randy Pope

From: Donna Lettow
Date: Mon, Feb 13 2012 7:00AM
Subject: Re: Using Tables
← Previous message | Next message →

Steve Faulkner:

>many aspects of HTML5 are here right now and being used so it makes sense take it into account.Part of the accessibility support problem is/has

> been that what is in specs and what is supported are not always the same thing.

> As accessibility practitioners we need to be mindful of this and provide best practise advice based on implementation realities.

As someone who is not currently a programmer/developer, but whose charge it is to ensure accessibility to my vocational rehabilitation constituents -- many of whom do not have access to the latest and greatest technology and who cannot afford to update JAWS each and every time Freedom Scientific releases a new version, and many of whom are not technologically savvy enough to know that people on Internet mailing lists mock the versions of Internet Explorer that they run (or that they run Internet Explorer at all) because they've never been taught how to update it - I worry that this rush to embrace the shiny new toys of HTML5 and ARIA is going to leave behind an accessibility underclass who won't have the equipment or the navigation skills to keep up.



When you're building your shiny new Ferraris for the Power Users, please make sure the little old lady who just wants to drive to the supermarket still can.



Donna Lettow

Staff Specialist, Electronic Accessibility & Internal Communication

MD Division of Rehabilitation Services






IMPORTANT NOTICE: This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

From: Steve Faulkner
Date: Mon, Feb 13 2012 7:15AM
Subject: Re: Using Tables
← Previous message | Next message →

Hi Donna,

>When you're building your shiny new Ferraris for the Power Users, please
make sure the little old lady who just wants to drive to the supermarket
still can.

It is not people such as myself who build such things, it is companies such
as google, yahoo, microsft, IBM etc.
Yes they need to take into account there users, but if they do choose to
use newer aspects of the technology that don't work in IE6, the
technologies still need to be accessible with whatever baseline
technologies these companies choose to support, that is where ARIA and
understanding how to build accessible interfaces with newer HTMl5 features
comes into play.

We also need to take into account that many traditional software
applications are now built using web technologies, these may well not be
published n the open web for all to access, but accessed via company
intranets. In such cases baseline technology requirements can be reasonably
defined (as they are with more traditional desktop software) and therefore
not every user agent or version can be expected to be catered for.

regards
Stevef


On 13 February 2012 14:02, Donna Lettow < = EMAIL ADDRESS REMOVED = > wrote:

> Steve Faulkner:
>
> >many aspects of HTML5 are here right now and being used so it makes sense
> take it into account.Part of the accessibility support problem is/has
>
> > been that what is in specs and what is supported are not always the same
> thing.
>
> > As accessibility practitioners we need to be mindful of this and provide
> best practise advice based on implementation realities.
>
> As someone who is not currently a programmer/developer, but whose charge
> it is to ensure accessibility to my vocational rehabilitation constituents
> -- many of whom do not have access to the latest and greatest technology
> and who cannot afford to update JAWS each and every time Freedom Scientific
> releases a new version, and many of whom are not technologically savvy
> enough to know that people on Internet mailing lists mock the versions of
> Internet Explorer that they run (or that they run Internet Explorer at all)
> because they've never been taught how to update it - I worry that this rush
> to embrace the shiny new toys of HTML5 and ARIA is going to leave behind an
> accessibility underclass who won't have the equipment or the navigation
> skills to keep up.
>
>
>
> When you're building your shiny new Ferraris for the Power Users, please
> make sure the little old lady who just wants to drive to the supermarket
> still can.
>
>
>
> Donna Lettow
>
> Staff Specialist, Electronic Accessibility & Internal Communication
>
> MD Division of Rehabilitation Services
>
>
>
>
>
>
> IMPORTANT NOTICE: This e-mail may contain confidential or privileged
> information. If you are not the intended recipient, please notify the
> sender immediately and destroy this e-mail. Any unauthorized copying,
> disclosure or distribution of the material in this e-mail is strictly
> forbidden.
>

From: Giovanni Duarte
Date: Mon, Feb 13 2012 7:51AM
Subject: Re: Using Tables
← Previous message | Next message →

Interesting topic about HTML5, the future, and current constraints...
I have heard from coworkers and managers that accessibility basically
translates to "simplicity" and lack of innovation. People is usually under
the assumption that accessibility and innovation can't go hand to hand. I
completely understand the need to provide support (as much as we can) to
those with older technologies; however, isn't this preventing us to
innovative and be more creative? For example, we can't keep supporting
Internet Explorer 6 anymore due to the technologies we use in our
institution. If we try to support IE6, we won't be able to implement more
than half of our technologies and benefit all the population.

All I am saying is that we need to find a balance so we can benefit everyone
without compromising the need of innovation and creativity.

Thanks,
Giovanni

From: Birkir R. Gunnarsson
Date: Mon, Feb 13 2012 7:57AM
Subject: Re: Using Tables
← Previous message | Next message →

I generally find that it would be more useful to have the table
summary attribute a link (either to a different page or expanding
text) that includes more detailed description that the table summaries
I have seen on the web generally contain.
Something along the lines of
"this table has 7 column, the first one is x and enables you to do y ..."
This would, of course, only be needed in case where the table
structure and associations are not obvious.
In other words, I believe where table summaries are really needed,they
are probably often expansive text that only needs to be read once.
I have, therefore, generally included a table summary type link above
the table, often hidden, with text that explain the use of the table
in detail, if I feel the need to include such summary, a bit more like
longdesc or providing alternative to audio or video by providing text
transcript almost.
Cheers
-B

On 2/13/12, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Donna,
>
>>When you're building your shiny new Ferraris for the Power Users, please
> make sure the little old lady who just wants to drive to the supermarket
> still can.
>
> It is not people such as myself who build such things, it is companies such
> as google, yahoo, microsft, IBM etc.
> Yes they need to take into account there users, but if they do choose to
> use newer aspects of the technology that don't work in IE6, the
> technologies still need to be accessible with whatever baseline
> technologies these companies choose to support, that is where ARIA and
> understanding how to build accessible interfaces with newer HTMl5 features
> comes into play.
>
> We also need to take into account that many traditional software
> applications are now built using web technologies, these may well not be
> published n the open web for all to access, but accessed via company
> intranets. In such cases baseline technology requirements can be reasonably
> defined (as they are with more traditional desktop software) and therefore
> not every user agent or version can be expected to be catered for.
>
> regards
> Stevef
>
>
> On 13 February 2012 14:02, Donna Lettow < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Steve Faulkner:
>>
>> >many aspects of HTML5 are here right now and being used so it makes sense
>> take it into account.Part of the accessibility support problem is/has
>>
>> > been that what is in specs and what is supported are not always the same
>> thing.
>>
>> > As accessibility practitioners we need to be mindful of this and provide
>> best practise advice based on implementation realities.
>>
>> As someone who is not currently a programmer/developer, but whose charge
>> it is to ensure accessibility to my vocational rehabilitation constituents
>> -- many of whom do not have access to the latest and greatest technology
>> and who cannot afford to update JAWS each and every time Freedom
>> Scientific
>> releases a new version, and many of whom are not technologically savvy
>> enough to know that people on Internet mailing lists mock the versions of
>> Internet Explorer that they run (or that they run Internet Explorer at
>> all)
>> because they've never been taught how to update it - I worry that this
>> rush
>> to embrace the shiny new toys of HTML5 and ARIA is going to leave behind
>> an
>> accessibility underclass who won't have the equipment or the navigation
>> skills to keep up.
>>
>>
>>
>> When you're building your shiny new Ferraris for the Power Users, please
>> make sure the little old lady who just wants to drive to the supermarket
>> still can.
>>
>>
>>
>> Donna Lettow
>>
>> Staff Specialist, Electronic Accessibility & Internal Communication
>>
>> MD Division of Rehabilitation Services
>>
>>
>>
>>
>>
>>
>> IMPORTANT NOTICE: This e-mail may contain confidential or privileged
>> information. If you are not the intended recipient, please notify the
>> sender immediately and destroy this e-mail. Any unauthorized copying,
>> disclosure or distribution of the material in this e-mail is strictly
>> forbidden.
>>

From: Donna Lettow
Date: Tue, Feb 14 2012 7:12AM
Subject: Re: Using Tables
← Previous message | Next message →

Don't get me wrong -- I'm not actually talking about IE6. I do understand the need to not code for IE6. (However, my entire agency just stopped using it a couple years ago, so I also understand that it's still out there.)

I'm talking about people who won't jump to use IE 10 the day it comes out because IE7 or 8 gets them where they need to go -- and likewise see no point to trying a different brand of browser. I'm talking about people who have learned enough to navigate their way around and do what they need to do with a TAB key, some arrows and a few basic commands. They're not Power Users because in their lives they don't need to be. And, yes, it's about some who don't have $1,000 to keep dropping on newer versions of JAWS that can support this constantly tweaked new technology because they need to pay their rent instead.

Electronic accessibility has opened a whole new world for some of my constituents. I just ask that you remember the non-Power Users when you're pulling out your bag of new toys and make sure they can still use them, too. It's one thing when some clueless hot-shot Flash programmer puts together a site that someone with basic screen reader skills can't access. It would be a shame if we the a11y community developed a class of "accessible" sites that turned out to be not so accessible to a certain class of screen reader users.

Sorry for the soap box, but among my co-workers are both Power Users and non-Power Users, and it's always illuminating when I need to test something.

Donna Lettow
Staff Specialist, Electronic Accessibility & Internal Communication
MD Division of Rehabilitation Services

IMPORTANT NOTICE: This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

From: Sailesh Panchang
Date: Tue, Feb 14 2012 11:24AM
Subject: Re: Using Tables
← Previous message | Next message →

Well I disagree with most arguments here against the summary attribute:
It is part of HTML 4 and for a very specific purpose: to help
non-visual users comprehend the structure / organization of a data
table’s content. This applies to tables that have a really complex
structure.
It may also be used to highlight key / salient values or a data range
especially in large or complex tables.

Some tables containing labor / census / financial data, for example,
can become really complex and large. Students, researchers, analysts
etc. need to access such data and may have no means to re-design the
work of other authors.
Consider tables that have more than 5 or 6 columns, that not only use
colspan but also rowspan. Some may even have 3 rows of column headers
and over 20 rows of data. And again data rows may be grouped.
The description for WCAG2 technique H73 is pretty much based on my
input and captures the above thoughts.
Indeed breaking up a complex table into smaller tables is one
solution butthen it may not be possible to convey the complexity,
dimensions and relationships across multiple attributes that the
table-designer intends to portray through one table. Space /
document’s length constraints may also limit the ability of the author
to use multiple data tables in place of one complex table.
More importantly, often tables on the Web are often a replica of
something that appears in print and the Web content author may not
have the liberty to re-design the table.
It is in these situations the summary plays a critical role. It can
certainly be dispensed with for less complex tables.
The problem is that the average developer / content author puts in a
summary attribute because he has been told to. Few grasp or comprehend
how it will be consumed by the end-user: the blind chap using
assistive technology. And that’s why one does not see examples of good
summaries on the Web in the wild.
Just because there are some reckless drivers or because accidents
happen, one does not ban the manufacture, sale and use of cars!
And certainly when there are complex tables in a document (or Web
page) the author always has the liberty to explain the complexities
in a paragraph before / after the table or on a separate linked page
for the benefit of all readers. There is no ban on doing this. If
textual explanation accessible to all users is present, the table
summary attribute may not be required at all or may not have to be
very elaborate.
And yet even with such an explanation, users who cannot see may still
need some extra help because it is indeed very challenging to review
and comprehend complex data structures using text to speech (or
Braille) interface. It is very different from a visual interface. The
summary attribute’s content is really meant for users who cannot see.
And for this reason it is criminal if HTML5 does away with this
important attribute designed to enhance accessibility of complex /
large data table to non-visual users. Perhaps it should be improved
so that an assistive technology user may access it whenever he needs
to and not be forced to read it everytime one navigates to the table.
Sailesh Panchang
Deque Systems
www.deque.com


On 2/10/12, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Fri, Feb 10, 2012 at 12:23 PM, Ted wrote:
>> Definitely need a summary for complex tables.
>
> I disagree. A few reasons why I think summary is almost universally a bad
> idea:
>
> 1. If the table is so complex that its structure needs to be explained
> to the user, it's too complex. Period.
>
> 2. Summary is screen-reader only and is forced upon the screen reader
> user each time the table is encountered. With proper table markup, the
> user should be able to quickly navigate the table to determine its
> content and structure, in the same way that sighted users must scan a
> table to determine its content and structure.
>
> 3. Summary is currently not part of HTML5.
>
> 4. Summary is NOT for presenting the purpose or content of the table.
> It's for describing its structure, when necessary (see #1). Probably
> 90% of summary attributes on the web get this wrong. If it's important
> that the purpose or content of the table be presented, this should be
> done in a way that is accessible to everyone (e.g., <caption>, etc.).
>
> It's a rarity to find a summary attribute that does much good. They
> are almost always a waste of time or an excuse for presenting an
> overly complex table. Or both.
>
> And no, I don't have strong feeling on the subject. :-)
>
> Jared
>

From: Steve Faulkner
Date: Tue, Feb 14 2012 12:06PM
Subject: Re: Using Tables
← Previous message | Next message →

Hi Sailesh,

"The
summary attribute’s content is really meant for users who cannot see.
And for this reason it is criminal if HTML5 does away with this
important attribute designed to enhance accessibility of complex /
large data table to non-visual users. Perhaps it should be improved
so that an assistive technology user may access it whenever he needs
to and not be forced to read it everytime one navigates to the table."

If you have any convincing data on summary attribute usage that could be
used to support the retention of the summaru attribute please provide it,
as that is what will keep it conforming in HTML5.

It has been around for 10 years+ so there should be good examples of its
use.

Also if browsers and assistive technology could be persuaded to support it
(if they do not) or improve current support, then that would go along way
to making its retention a reality. Any help you could provide in this
regard wuld be appreciated.

best regards
stevef

On 14 February 2012 18:26, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >wrote:

> Well I disagree with most arguments here against the summary attribute:
> It is part of HTML 4 and for a very specific purpose: to help
> non-visual users comprehend the structure / organization of a data
> table’s content. This applies to tables that have a really complex
> structure.
> It may also be used to highlight key / salient values or a data range
> especially in large or complex tables.
>
> Some tables containing labor / census / financial data, for example,
> can become really complex and large. Students, researchers, analysts
> etc. need to access such data and may have no means to re-design the
> work of other authors.
> Consider tables that have more than 5 or 6 columns, that not only use
> colspan but also rowspan. Some may even have 3 rows of column headers
> and over 20 rows of data. And again data rows may be grouped.
> The description for WCAG2 technique H73 is pretty much based on my
> input and captures the above thoughts.
> Indeed breaking up a complex table into smaller tables is one
> solution butthen it may not be possible to convey the complexity,
> dimensions and relationships across multiple attributes that the
> table-designer intends to portray through one table. Space /
> document’s length constraints may also limit the ability of the author
> to use multiple data tables in place of one complex table.
> More importantly, often tables on the Web are often a replica of
> something that appears in print and the Web content author may not
> have the liberty to re-design the table.
> It is in these situations the summary plays a critical role. It can
> certainly be dispensed with for less complex tables.
> The problem is that the average developer / content author puts in a
> summary attribute because he has been told to. Few grasp or comprehend
> how it will be consumed by the end-user: the blind chap using
> assistive technology. And that’s why one does not see examples of good
> summaries on the Web in the wild.
> Just because there are some reckless drivers or because accidents
> happen, one does not ban the manufacture, sale and use of cars!
> And certainly when there are complex tables in a document (or Web
> page) the author always has the liberty to explain the complexities
> in a paragraph before / after the table or on a separate linked page
> for the benefit of all readers. There is no ban on doing this. If
> textual explanation accessible to all users is present, the table
> summary attribute may not be required at all or may not have to be
> very elaborate.
> And yet even with such an explanation, users who cannot see may still
> need some extra help because it is indeed very challenging to review
> and comprehend complex data structures using text to speech (or
> Braille) interface. It is very different from a visual interface. The
> summary attribute’s content is really meant for users who cannot see.
> And for this reason it is criminal if HTML5 does away with this
> important attribute designed to enhance accessibility of complex /
> large data table to non-visual users. Perhaps it should be improved
> so that an assistive technology user may access it whenever he needs
> to and not be forced to read it everytime one navigates to the table.
> Sailesh Panchang
> Deque Systems
> www.deque.com
>
>
> On 2/10/12, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> > On Fri, Feb 10, 2012 at 12:23 PM, Ted wrote:
> >> Definitely need a summary for complex tables.
> >
> > I disagree. A few reasons why I think summary is almost universally a bad
> > idea:
> >
> > 1. If the table is so complex that its structure needs to be explained
> > to the user, it's too complex. Period.
> >
> > 2. Summary is screen-reader only and is forced upon the screen reader
> > user each time the table is encountered. With proper table markup, the
> > user should be able to quickly navigate the table to determine its
> > content and structure, in the same way that sighted users must scan a
> > table to determine its content and structure.
> >
> > 3. Summary is currently not part of HTML5.
> >
> > 4. Summary is NOT for presenting the purpose or content of the table.
> > It's for describing its structure, when necessary (see #1). Probably
> > 90% of summary attributes on the web get this wrong. If it's important
> > that the purpose or content of the table be presented, this should be
> > done in a way that is accessible to everyone (e.g., <caption>, etc.).
> >
> > It's a rarity to find a summary attribute that does much good. They
> > are almost always a waste of time or an excuse for presenting an
> > overly complex table. Or both.
> >
> > And no, I don't have strong feeling on the subject. :-)
> >
> > Jared
> >

From: Ryan Hemphill
Date: Tue, Feb 14 2012 12:30PM
Subject: Re: Using Tables
← Previous message | Next message →

I have read through all the passionate comments here and I find myself
wondering if there isn't another way to approach these things. It feels
like every single time someone comes up with a new widget that
accessibility implementations are playing catchup...and often failing.

Would it make any sense to start breaking down the behaviors that screen
readers have into something more basic? I am starting to think that we're
always going to be behind the curve if we don't find some way to simplify
this stuff more. I'm not sure that HTML5 is even really the issue here.
It feels like the system for reading a rich internet application needs to
be more granular before it's going to work - I feel like we're stuck
talking about things like the summary attribute when maybe we need to find
a way that the value of the summary attribute and anything like it is kept
without having to be retuned into a constantly mutating spec like HTML5.

Sorry if this sounds confusing - I am just having a hard time seeing how we
move forward with a moving target like this - I think we need to figure out
a way to make this much more basic in nature to begin with.

- Ryan


On Tue, Feb 14, 2012 at 2:09 PM, Steve Faulkner < = EMAIL ADDRESS REMOVED = >wrote:

> Hi Sailesh,
>
> "The
> summary attribute’s content is really meant for users who cannot see.
> And for this reason it is criminal if HTML5 does away with this
> important attribute designed to enhance accessibility of complex /
> large data table to non-visual users. Perhaps it should be improved
> so that an assistive technology user may access it whenever he needs
> to and not be forced to read it everytime one navigates to the table."
>
> If you have any convincing data on summary attribute usage that could be
> used to support the retention of the summaru attribute please provide it,
> as that is what will keep it conforming in HTML5.
>
> It has been around for 10 years+ so there should be good examples of its
> use.
>
> Also if browsers and assistive technology could be persuaded to support it
> (if they do not) or improve current support, then that would go along way
> to making its retention a reality. Any help you could provide in this
> regard wuld be appreciated.
>
> best regards
> stevef
>
> On 14 February 2012 18:26, Sailesh Panchang < = EMAIL ADDRESS REMOVED =
> >wrote:
>
> > Well I disagree with most arguments here against the summary attribute:
> > It is part of HTML 4 and for a very specific purpose: to help
> > non-visual users comprehend the structure / organization of a data
> > table’s content. This applies to tables that have a really complex
> > structure.
> > It may also be used to highlight key / salient values or a data range
> > especially in large or complex tables.
> >
> > Some tables containing labor / census / financial data, for example,
> > can become really complex and large. Students, researchers, analysts
> > etc. need to access such data and may have no means to re-design the
> > work of other authors.
> > Consider tables that have more than 5 or 6 columns, that not only use
> > colspan but also rowspan. Some may even have 3 rows of column headers
> > and over 20 rows of data. And again data rows may be grouped.
> > The description for WCAG2 technique H73 is pretty much based on my
> > input and captures the above thoughts.
> > Indeed breaking up a complex table into smaller tables is one
> > solution butthen it may not be possible to convey the complexity,
> > dimensions and relationships across multiple attributes that the
> > table-designer intends to portray through one table. Space /
> > document’s length constraints may also limit the ability of the author
> > to use multiple data tables in place of one complex table.
> > More importantly, often tables on the Web are often a replica of
> > something that appears in print and the Web content author may not
> > have the liberty to re-design the table.
> > It is in these situations the summary plays a critical role. It can
> > certainly be dispensed with for less complex tables.
> > The problem is that the average developer / content author puts in a
> > summary attribute because he has been told to. Few grasp or comprehend
> > how it will be consumed by the end-user: the blind chap using
> > assistive technology. And that’s why one does not see examples of good
> > summaries on the Web in the wild.
> > Just because there are some reckless drivers or because accidents
> > happen, one does not ban the manufacture, sale and use of cars!
> > And certainly when there are complex tables in a document (or Web
> > page) the author always has the liberty to explain the complexities
> > in a paragraph before / after the table or on a separate linked page
> > for the benefit of all readers. There is no ban on doing this. If
> > textual explanation accessible to all users is present, the table
> > summary attribute may not be required at all or may not have to be
> > very elaborate.
> > And yet even with such an explanation, users who cannot see may still
> > need some extra help because it is indeed very challenging to review
> > and comprehend complex data structures using text to speech (or
> > Braille) interface. It is very different from a visual interface. The
> > summary attribute’s content is really meant for users who cannot see.
> > And for this reason it is criminal if HTML5 does away with this
> > important attribute designed to enhance accessibility of complex /
> > large data table to non-visual users. Perhaps it should be improved
> > so that an assistive technology user may access it whenever he needs
> > to and not be forced to read it everytime one navigates to the table.
> > Sailesh Panchang
> > Deque Systems
> > www.deque.com
> >
> >
> > On 2/10/12, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> > > On Fri, Feb 10, 2012 at 12:23 PM, Ted wrote:
> > >> Definitely need a summary for complex tables.
> > >
> > > I disagree. A few reasons why I think summary is almost universally a
> bad
> > > idea:
> > >
> > > 1. If the table is so complex that its structure needs to be explained
> > > to the user, it's too complex. Period.
> > >
> > > 2. Summary is screen-reader only and is forced upon the screen reader
> > > user each time the table is encountered. With proper table markup, the
> > > user should be able to quickly navigate the table to determine its
> > > content and structure, in the same way that sighted users must scan a
> > > table to determine its content and structure.
> > >
> > > 3. Summary is currently not part of HTML5.
> > >
> > > 4. Summary is NOT for presenting the purpose or content of the table.
> > > It's for describing its structure, when necessary (see #1). Probably
> > > 90% of summary attributes on the web get this wrong. If it's important
> > > that the purpose or content of the table be presented, this should be
> > > done in a way that is accessible to everyone (e.g., <caption>, etc.).
> > >
> > > It's a rarity to find a summary attribute that does much good. They
> > > are almost always a waste of time or an excuse for presenting an
> > > overly complex table. Or both.
> > >
> > > And no, I don't have strong feeling on the subject. :-)
> > >
> > > Jared
> > >

From: Sailesh Panchang
Date: Tue, Feb 14 2012 3:18PM
Subject: Re: Using Tables
← Previous message | Next message →

Steve,
The need is for better education about the summary attribute as my
email reasons.
Sure I have recommended clients use the summary attribute several
times to clients. I cannot look for those pages now... Web content
changes and pages are redesigned.
Priceline used to have this summary some years ago based on our
recommendation for flights results page:
Summary="This table contains n rows and m columns. The rows represent
non-stop, 1 stop, and 2+ stops (a single row is provided for
Multi-Destination itineraries).
The columns represent your choice of airlines. Clicking on the price
shown in each cell will redisplay this page with only flights matching
the airline
and number of flights selected. Clicking on a stop category or airline
will display all flights within that category."
Note : we did not suggest that it should state how many cols and
rows the table contains.
Also see the attached table for another good example.

Sailesh

On 2/14/12, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Sailesh,
>
> "The
> summary attribute’s content is really meant for users who cannot see.
> And for this reason it is criminal if HTML5 does away with this
> important attribute designed to enhance accessibility of complex /
> large data table to non-visual users. Perhaps it should be improved
> so that an assistive technology user may access it whenever he needs
> to and not be forced to read it everytime one navigates to the table."
>
> If you have any convincing data on summary attribute usage that could be
> used to support the retention of the summaru attribute please provide it,
> as that is what will keep it conforming in HTML5.
>
> It has been around for 10 years+ so there should be good examples of its
> use.
>
> Also if browsers and assistive technology could be persuaded to support it
> (if they do not) or improve current support, then that would go along way
> to making its retention a reality. Any help you could provide in this
> regard wuld be appreciated.
>
> best regards
> stevef
>
> On 14 February 2012 18:26, Sailesh Panchang
> < = EMAIL ADDRESS REMOVED = >wrote:
>
>> Well I disagree with most arguments here against the summary attribute:
>> It is part of HTML 4 and for a very specific purpose: to help
>> non-visual users comprehend the structure / organization of a data
>> table’s content. This applies to tables that have a really complex
>> structure.
>> It may also be used to highlight key / salient values or a data range
>> especially in large or complex tables.
>>
>> Some tables containing labor / census / financial data, for example,
>> can become really complex and large. Students, researchers, analysts
>> etc. need to access such data and may have no means to re-design the
>> work of other authors.
>> Consider tables that have more than 5 or 6 columns, that not only use
>> colspan but also rowspan. Some may even have 3 rows of column headers
>> and over 20 rows of data. And again data rows may be grouped.
>> The description for WCAG2 technique H73 is pretty much based on my
>> input and captures the above thoughts.
>> Indeed breaking up a complex table into smaller tables is one
>> solution butthen it may not be possible to convey the complexity,
>> dimensions and relationships across multiple attributes that the
>> table-designer intends to portray through one table. Space /
>> document’s length constraints may also limit the ability of the author
>> to use multiple data tables in place of one complex table.
>> More importantly, often tables on the Web are often a replica of
>> something that appears in print and the Web content author may not
>> have the liberty to re-design the table.
>> It is in these situations the summary plays a critical role. It can
>> certainly be dispensed with for less complex tables.
>> The problem is that the average developer / content author puts in a
>> summary attribute because he has been told to. Few grasp or comprehend
>> how it will be consumed by the end-user: the blind chap using
>> assistive technology. And that’s why one does not see examples of good
>> summaries on the Web in the wild.
>> Just because there are some reckless drivers or because accidents
>> happen, one does not ban the manufacture, sale and use of cars!
>> And certainly when there are complex tables in a document (or Web
>> page) the author always has the liberty to explain the complexities
>> in a paragraph before / after the table or on a separate linked page
>> for the benefit of all readers. There is no ban on doing this. If
>> textual explanation accessible to all users is present, the table
>> summary attribute may not be required at all or may not have to be
>> very elaborate.
>> And yet even with such an explanation, users who cannot see may still
>> need some extra help because it is indeed very challenging to review
>> and comprehend complex data structures using text to speech (or
>> Braille) interface. It is very different from a visual interface. The
>> summary attribute’s content is really meant for users who cannot see.
>> And for this reason it is criminal if HTML5 does away with this
>> important attribute designed to enhance accessibility of complex /
>> large data table to non-visual users. Perhaps it should be improved
>> so that an assistive technology user may access it whenever he needs
>> to and not be forced to read it everytime one navigates to the table.
>> Sailesh Panchang
>> Deque Systems
>> www.deque.com
>>
>>
>> On 2/10/12, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>> > On Fri, Feb 10, 2012 at 12:23 PM, Ted wrote:
>> >> Definitely need a summary for complex tables.
>> >
>> > I disagree. A few reasons why I think summary is almost universally a
>> > bad
>> > idea:
>> >
>> > 1. If the table is so complex that its structure needs to be explained
>> > to the user, it's too complex. Period.
>> >
>> > 2. Summary is screen-reader only and is forced upon the screen reader
>> > user each time the table is encountered. With proper table markup, the
>> > user should be able to quickly navigate the table to determine its
>> > content and structure, in the same way that sighted users must scan a
>> > table to determine its content and structure.
>> >
>> > 3. Summary is currently not part of HTML5.
>> >
>> > 4. Summary is NOT for presenting the purpose or content of the table.
>> > It's for describing its structure, when necessary (see #1). Probably
>> > 90% of summary attributes on the web get this wrong. If it's important
>> > that the purpose or content of the table be presented, this should be
>> > done in a way that is accessible to everyone (e.g., <caption>, etc.).
>> >
>> > It's a rarity to find a summary attribute that does much good. They
>> > are almost always a waste of time or an excuse for presenting an
>> > overly complex table. Or both.
>> >
>> > And no, I don't have strong feeling on the subject. :-)
>> >
>> > Jared
>> >

From: Joshue O Connor CFIT
Date: Wed, Feb 15 2012 2:00AM
Subject: Re: Using Tables
← Previous message | Next message →

Hi all,

Thanks to Laura and Sailesh for giving me a heads up about this thread.

Here is a list of @summary examples in the wild that are attached to the
latest change proposal for @summary in the HTML5 WG.

You can see them at. [1]

The change proposal itself it at. [2]

As I've said many times, I find @summary to be just a simple, useful
attribute, that was well supported but often just simply neglected. An
accessibility diamond, if you will. It was amazing to me how many here
have had to fight to 'save' it, thought the net result is unfortunately
obsoletion. I also think many in the accessibility community are just
not really bothered with it anymore. This is probably partially due to
burn out, and being at the tail end of the 'a11y war of attrition (2006
- ?)'. There are - in fairness - many other issues that require
attention. FFIW, It was a no brainer - to me - to keep @summary as I had
seen it in use by my blind friends in user tests, and thought it did
what it did very well. But I do feel I failed somewhat in translating
what was obvious to me, to others in the HTML5 WG.

I also disagree with Jared. @summary doesn't have to just rigidly just
give a structural overview of complex tables (no matter what it says in
the spec). It can be used to provide additional supplementary
information to a blind person that can aid comprehension of any table
and its contents. They won't be swamped as they navigate a page with
tables because as soon as they give focus to another HTML element the
can skip the @summary (or indeed just silence JAWS etc).

Anyway, it is academic now so at this stage I'm adopting a Forrest Gump
stance, "that's all I have to say about that".

Cheers

Josh

[1]
http://www.w3.org/html/wg/wiki/ChangeProposals/ReinstateTableSummary/RealWorldExamples

[2] http://www.w3.org/html/wg/wiki/ChangeProposals/ReinstateTableSummary

Follow us on Facebook: https://www.facebook.com/ncbiworkingforpeoplewithsightloss
Follow us on Twitter: www.twitter.com/ncbi_sightloss

Check-out NCBI's Mícheál Ó Muircheartaigh appeal on the following link.
http://youtu.be/25P2tiuCi0U

********************************************************************
National Council for the Blind of Ireland (NCBI) is a company
limited by guarantee (registered in Ireland No. 26293) .
Our registered office is at Whitworth Road, Drumcondra, Dublin 9.
NCBI is also a registered Charity (chy4626).

NOTICE: The information contained in this email and any attachments
is confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of
the content of it or of any attachment; you are requested to notify
the sender immediately of your receipt of the email and then to
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated
by its staff are free from viruses or other contaminants. However,
it cannot accept any responsibility for any such which are
transmitted. We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email
and any attachments are those of the author and do not necessarily
represent the views of NCBI


********************************************************************

From: Laura Carlson
Date: Wed, Feb 15 2012 5:36AM
Subject: Re: Using Tables
← Previous message | Next message →

Hi Steve,

Steve Faulkner wrote:

> It [@summary] has been around for 10 years+ so there should be
> good examples of its use.

Gregory Rosmaita, Joshue O Connor and you have done some searching to
find table summary examples in the wild. I don't know of a good Goggle
query to use for table summary. Any ideas?

I suspect that good table summary examples are be behind firewalls:
Peoplesoft, bank sites etc. I don't know how it would be possible to
represent those to the HTML working group. And if it was the evidence
would probably be discounted as it is not available publicly.

Best Regards,
Laura
--
Laura L. Carlson

From: Sailesh Panchang
Date: Wed, Feb 15 2012 8:03AM
Subject: Re: Using Tables
← Previous message | Next message →

Well there is another useful technique (via CSS) off-screen text that
provides extra text to make links and form controls accessible
essentially only to users relying on screen reading/magnifying
technologies.
No one objects to that and in fact overuses / misues it at times in
places not suggested by accessibility guidelines.
In effect invisible text rendered by off-screen technique is not
much different from invisible text rendered by an HTML attribute to
fix an accessibility barrier.
Why does one not say throw off the off-screen technique out of the window?
In truth extensive incorrect application and misuse of the table
summary technique for tables that really do not need them has given
one the general impression that it is a nuisance and serves no
purpose. So use it correctly and only where required.
And that brings me to a favorite point I like to make and have
conveyed to the WCAG-WG: misuse of, or incorrect / inconsistent
application of accessibility technique itself becomes a barrier for
users of Web content.
Sailesh Panchang
www.deque.com



On 2/10/12, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Fri, Feb 10, 2012 at 12:23 PM, Ted wrote:
>> Definitely need a summary for complex tables.
>
> I disagree. A few reasons why I think summary is almost universally a bad
> idea:
>
> 1. If the table is so complex that its structure needs to be explained
> to the user, it's too complex. Period.
>
> 2. Summary is screen-reader only and is forced upon the screen reader
> user each time the table is encountered. With proper table markup, the
> user should be able to quickly navigate the table to determine its
> content and structure, in the same way that sighted users must scan a
> table to determine its content and structure.
>
> 3. Summary is currently not part of HTML5.
>
> 4. Summary is NOT for presenting the purpose or content of the table.
> It's for describing its structure, when necessary (see #1). Probably
> 90% of summary attributes on the web get this wrong. If it's important
> that the purpose or content of the table be presented, this should be
> done in a way that is accessible to everyone (e.g., <caption>, etc.).
>
> It's a rarity to find a summary attribute that does much good. They
> are almost always a waste of time or an excuse for presenting an
> overly complex table. Or both.
>
> And no, I don't have strong feeling on the subject. :-)
>
> Jared
>

From: Jared Smith
Date: Wed, Feb 15 2012 8:36AM
Subject: Re: Using Tables
← Previous message | Next message →

On Wed, Feb 15, 2012 at 8:06 AM, Sailesh Panchang wrote:

> In effect  invisible text rendered by off-screen technique is not
> much different from invisible text rendered by an HTML attribute to
> fix an accessibility barrier.

It is different. For the most part, a form control is inaccessible
without a label whether it's on-screen or off-screen. A complex table
on the other hand, will still be generally inaccessible with or
without the summary. If the actual problem is resolved (the complexity
of the table), the summary would no longer be necessary.

> Why does one not say throw off the off-screen technique out of the window?

Because the off-screen technique actually resolves the inaccessibility
of page elements. In nearly all cases, the summary attribute (when
actually necessary) simply conflates a complex table with a verbose
description of that complexity.

> misuse of, or incorrect / inconsistent
> application  of accessibility technique itself becomes a barrier for
> users of Web content.

Absolutely! Which brings me to the list of examples that Joshue
provided. Of the dozens of examples, I found one (yes, only one)
summary that I thought was actually useful. Nearly all of the
summaries simply provided one or more of the following:
- a repetition of the visible caption or other visual text.
- a repetition of the table headers.
- a description of the number of rows and columns in the table.

All of this information is readily available to screen readers by
simply navigating to or within the table. Many of the summaries
provided irrelevant and verbose information that was not necessary or
that was already provided visually. If these are the best examples we
can come up with, it simply reinforces my thinking that table summary
really never is used correctly and should probably just go away.

Jared

From: Tim Harshbarger
Date: Wed, Feb 15 2012 9:54AM
Subject: Re: Using Tables
← Previous message | Next message →

> misuse of, or incorrect / inconsistent
> application of accessibility technique itself becomes a barrier for
> users of Web content.

I agree that misuse of techniques can cause problems, but I am uncertain that citing misuse of techniques is enough of a reason to deprecate or remove the use of a technique. There are also issues like what is the problem being solved?, How is the technique misused?, How is it used correctly?, et cetera.
I have seen bad uses of the summary attribute where it makes things more confusing. I have seen good uses of the summary attribute where it seemed to be helping users understand the table better. Most of the uses I have seen are not much of either. They don't make the table more difficult to use and they don't improve the understanding of the table. I'm uncertain if I would call those misuses of the technique. I might consider them more unnecessary applications of a technique.

From: Sailesh Panchang
Date: Wed, Feb 15 2012 11:45AM
Subject: Re: Using Tables
← Previous message | Next message →

Jared,
I am not trying to compare an inaccessible form control and an
inaccessible complex table and grade which one is more of a barrier. I
am pointing to _invisible text_ (off-screen) being considered alright
as a solution for helping one group of users (vision impaired) and
being frowned upon when _invisible text_ as a summary attribute is
used to mitigate the challenges posed by another barrier.
The email I sent yesterday evening has 2 good examples.
And when you say you found only one or two good examples in a batch
you reviewed, you are only reinforcing the point I have been making my
emails all the time: summary is needed only for really complex tables
as I explained in my first email. An again as I said before, one needs
to be aware of how the summary is used and the specific challenges
posed by a particular table before one can write a good summary. It is
a thoughtful process and needs to be drafted in a manner that serves
the end user.
Of course the table has to be marked up properly so data cells and
header cells are properly associated. But the summary helps one get
oriented to the complexity of the table's structure and adopt
appropriate navigation methods. And my first email yesterday explains
why complex tables cannot be wished away.
You are repeating what I said with great illustrations: the summary is
used excessively and mostly incorrectly making it a nuisance at most
times.
Tim- by saying that, I am not saying the summary should be dropped but
I am arguing for its retention and proper usage. I am on your side.
Sailesh Panchang




On 2/15/12, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Wed, Feb 15, 2012 at 8:06 AM, Sailesh Panchang wrote:
>
>> In effect invisible text rendered by off-screen technique is not
>> much different from invisible text rendered by an HTML attribute to
>> fix an accessibility barrier.
>
> It is different. For the most part, a form control is inaccessible
> without a label whether it's on-screen or off-screen. A complex table
> on the other hand, will still be generally inaccessible with or
> without the summary. If the actual problem is resolved (the complexity
> of the table), the summary would no longer be necessary.
>
>> Why does one not say throw off the off-screen technique out of the window?
>
> Because the off-screen technique actually resolves the inaccessibility
> of page elements. In nearly all cases, the summary attribute (when
> actually necessary) simply conflates a complex table with a verbose
> description of that complexity.
>
>> misuse of, or incorrect / inconsistent
>> application of accessibility technique itself becomes a barrier for
>> users of Web content.
>
> Absolutely! Which brings me to the list of examples that Joshue
> provided. Of the dozens of examples, I found one (yes, only one)
> summary that I thought was actually useful. Nearly all of the
> summaries simply provided one or more of the following:
> - a repetition of the visible caption or other visual text.
> - a repetition of the table headers.
> - a description of the number of rows and columns in the table.
>
> All of this information is readily available to screen readers by
> simply navigating to or within the table. Many of the summaries
> provided irrelevant and verbose information that was not necessary or
> that was already provided visually. If these are the best examples we
> can come up with, it simply reinforces my thinking that table summary
> really never is used correctly and should probably just go away.
>
> Jared
>

From: Sailesh Panchang
Date: Thu, Feb 23 2012 1:30PM
Subject: Re: Using Tables
← Previous message | No next message

Two opinions here:
1. http://www.456bereastreet.com/archive/200906/help_screen_reader_users_by_giving_data_tables_a_summary/
2. http://juicystudio.com/article/purpose-of-the-summary-attribute.php
Sailesh



On 2/15/12, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> Jared,
> I am not trying to compare an inaccessible form control and an
> inaccessible complex table and grade which one is more of a barrier. I
> am pointing to _invisible text_ (off-screen) being considered alright
> as a solution for helping one group of users (vision impaired) and
> being frowned upon when _invisible text_ as a summary attribute is
> used to mitigate the challenges posed by another barrier.
> The email I sent yesterday evening has 2 good examples.
> And when you say you found only one or two good examples in a batch
> you reviewed, you are only reinforcing the point I have been making my
> emails all the time: summary is needed only for really complex tables
> as I explained in my first email. An again as I said before, one needs
> to be aware of how the summary is used and the specific challenges
> posed by a particular table before one can write a good summary. It is
> a thoughtful process and needs to be drafted in a manner that serves
> the end user.
> Of course the table has to be marked up properly so data cells and
> header cells are properly associated. But the summary helps one get
> oriented to the complexity of the table's structure and adopt
> appropriate navigation methods. And my first email yesterday explains
> why complex tables cannot be wished away.
> You are repeating what I said with great illustrations: the summary is
> used excessively and mostly incorrectly making it a nuisance at most
> times.
> Tim- by saying that, I am not saying the summary should be dropped but
> I am arguing for its retention and proper usage. I am on your side.
> Sailesh Panchang
>
>
>
>
> On 2/15/12, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>> On Wed, Feb 15, 2012 at 8:06 AM, Sailesh Panchang wrote:
>>
>>> In effect invisible text rendered by off-screen technique is not
>>> much different from invisible text rendered by an HTML attribute to
>>> fix an accessibility barrier.
>>
>> It is different. For the most part, a form control is inaccessible
>> without a label whether it's on-screen or off-screen. A complex table
>> on the other hand, will still be generally inaccessible with or
>> without the summary. If the actual problem is resolved (the complexity
>> of the table), the summary would no longer be necessary.
>>
>>> Why does one not say throw off the off-screen technique out of the
>>> window?
>>
>> Because the off-screen technique actually resolves the inaccessibility
>> of page elements. In nearly all cases, the summary attribute (when
>> actually necessary) simply conflates a complex table with a verbose
>> description of that complexity.
>>
>>> misuse of, or incorrect / inconsistent
>>> application of accessibility technique itself becomes a barrier for
>>> users of Web content.
>>
>> Absolutely! Which brings me to the list of examples that Joshue
>> provided. Of the dozens of examples, I found one (yes, only one)
>> summary that I thought was actually useful. Nearly all of the
>> summaries simply provided one or more of the following:
>> - a repetition of the visible caption or other visual text.
>> - a repetition of the table headers.
>> - a description of the number of rows and columns in the table.
>>
>> All of this information is readily available to screen readers by
>> simply navigating to or within the table. Many of the summaries
>> provided irrelevant and verbose information that was not necessary or
>> that was already provided visually. If these are the best examples we
>> can come up with, it simply reinforces my thinking that table summary
>> really never is used correctly and should probably just go away.
>>
>> Jared
>>