E-mail List Archives
Re: Using Tables
From: Sailesh Panchang
Date: Feb 14, 2012 3:18PM
- Next message: Joshue O Connor CFIT: "Re: Using Tables"
- Previous message: Ryan Hemphill: "Re: Using Tables"
- Next message in Thread: Joshue O Connor CFIT: "Re: Using Tables"
- Previous message in Thread: Ryan Hemphill: "Re: Using Tables"
- View all messages in this Thread
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 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
>> >
- Next message: Joshue O Connor CFIT: "Re: Using Tables"
- Previous message: Ryan Hemphill: "Re: Using Tables"
- Next message in Thread: Joshue O Connor CFIT: "Re: Using Tables"
- Previous message in Thread: Ryan Hemphill: "Re: Using Tables"
- View all messages in this Thread