WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Using Tables

for

From: Ryan Hemphill
Date: Feb 14, 2012 12:30PM

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 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 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 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
> > >