E-mail List Archives
Thread: summary or caption
Number of posts in this thread: 19 (In chronological order)
From: Stanzel, Susan - FSA, Kansas City, MO
Date: Fri, Jun 07 2013 6:50AM
Subject: summary or caption
No previous message | Next message →
When creating a table of data should I use a summary or caption?
Susie
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
From: Jukka K. Korpela
Date: Fri, Jun 07 2013 8:35AM
Subject: Re: summary or caption
← Previous message | Next message →
2013-06-07 15:50, Stanzel, Susan - FSA, Kansas City, MO wrote:
> When creating a table of data should I use a summary or caption?
Yes, mostly. :-)
Seriously, a caption element is normally useful, even essential, for a
table of data. For example, it helps a cognitively challenged person,
and often any person, to understand what the table is about and why it
is there. Without a caption, people may get lost in the data and may
start looking for explanations in the text, possibly in vain, possibly
getting disoriented. A caption often helps to understand the role of a
table on a page and perhaps to skip it if it irrelevant to the user or
to read it extra carefully if it is crucial to him.
The summary attribute is much more controversial. It has even been
dropped from the HTML5 CR, though the debate goes on and it might get
re-established. Briefly, you could use the summary attribute if there is
something important to say about the table but the information is
expected to be self-evident to a person who sees the table at a glance.
For example, it might be relevant that the entries are in alphabetic
order, but most people will see that without saying. An attribute like
summary="The table is in alphabetic order by surname" might be useful.
The summary attribute should be used, if at all, as complementary to the
caption element. The caption is for everyone, and the summary is
additional annotations that may benefit some people.
Yucca
From: Don Mauck
Date: Fri, Jun 07 2013 9:43AM
Subject: Re: summary or caption
← Previous message | Next message →
I agree with most of what you say, however, in regards to the summary, you state that the summary is extra and might be useful to some people. I submit, a JAWS, NVDA or any other user of a screen reader will benefit from a good table summary.
From: Chagnon | PubCom
Date: Fri, Jun 07 2013 10:45AM
Subject: Re: summary or caption
← Previous message | Next message →
Devi's advocate chiming in.
"a JAWS, NVDA or any other user of a screen reader will benefit from a good
table summary."
1. Why should ONLY screen reader users benefit from a good table summary?
Shouldn't all users have access to the same information?
Remember, "summary" is an attribute on the <TABLE> tag, and it is not
visible to sighted users. If you put information in it that is not available
elsewhere, you could end up with a reverse-discrimination lawsuit.
2. The <CAPTION> tag is visible to everyone, AT-users and sighted users. If
you have a caption, why do you need a summary, too?
3. As an editor for many decades (as well as a programmer), I'd have to
split semantic hairs to describe the difference between a table caption and
a table summary, as they are defined in HTML/WCAG. Is this an example of
WCAG tag bloat - that is, too many tags, rules, guidelines,
whatever-you-want-to-call-them with a lot of overlap in functionality? Does
the W3C and WAI need more editors to help them select better names/labels
for these elements?
4. As an editor, I believe that a good table should have a title, subtitle,
caption, and column headers that adequately provide this information to
everyone whether they are using AT or not. This information is built into
the body of the table for everyone to see, regardless of the technology they
are using.
So, if you're thinking that some tag will help people use the information in
a table, stop. Instead, go hire a competent editor to write/edit a better
table. Creating another tag, attribute, or other markup doesn't completely
fix the problem because often the problem is a poorly written and edited
table.
-Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New schedule for classes and workshops coming in 2013.
From: Don Mauck
Date: Fri, Jun 07 2013 11:54AM
Subject: Re: summary or caption
← Previous message | Next message →
Yes, of course I never said not to have table captions as well, benefits all then.
From: Jonathan Metz
Date: Fri, Jun 07 2013 12:21PM
Subject: Re: summary or caption
← Previous message | Next message →
I¹m going to try to avoid the urge to wax on about the silliness of
calling something ³reverse" discrimination. :)
Only screen reader users should benefit from some content because that is
the intended audience. Users who do not require AT do not require the
benefits of them (arguably).
There are plenty of things we hide from users when coding. By your logic,
are we also at risk for being sued by users who can¹t see comments in
HTML, which are intended for other web designers? Or worse, when it¹s in
the CSS which require you to locate and access those pages?
In my opinion, if a tag has been deprecated there is probably a reason, so
unless you are aiming your content for a desired audience that uses
technology that still uses that tag, I would just omit it altogether.
That¹s just my reasoning. I wouldn¹t be too worried about getting sued by
someone who¹s case would most likely get thrown out of court.
Jonathan
On 6/7/13 1:54 PM, "Don Mauck" < = EMAIL ADDRESS REMOVED = > wrote:
>Yes, of course I never said not to have table captions as well, benefits
>all then.
>
From: Chagnon | PubCom
Date: Fri, Jun 07 2013 1:02PM
Subject: Re: summary or caption
← Previous message | Next message →
Jonathan wrote: "Only screen reader users should benefit from some content
because that is the intended audience"
It's rare that I've found a table where certain information needs to be
given to AT-users and hidden from the rest of the the audience. As I've
reviewed way-too-many tables in my job, I've seen the summary tag misused
for information like this: "This table is compiled from data collected in
2010-2011."
That's helpful information for everyone, yet because it's in a summary
attribute, it's hidden from the majority of users and available only to
AT-users. Maybe it will end up in court and maybe not, but it's a clear case
of discrimination: the same or equivalent info isn't being given to all
audiences.
However, if the summary attribute is used to give guidance to AT-users on
how to navigate the table, such as "data reads top-down, left-to-right," why
in the world call it a SUMMARY element? It's more a "how to read this table"
element/tag and not in any stretch of our language a "summary" of the
table's content.
Another case of an incorrect name given to an element or tag because the
name doesn't match its usage. I'm relieved that it's deprecated in HTML5.
As I stated before, the better solution is to edit the verbiage or
reconstruct the table so that it's obvious what the table is about and how
to read it.
Jonathan wrote: "By your logic, are we also at risk for being sued by users
who can¹t see comments in HTML "
Nah, your counter-argument doesn't fit here.
From what I've heard, current interpretation of Section 508 is that it
applies to public-facing information and internal information that federal
employees need to perform their jobs.
HTML source code, with all of its comments, CSS, and other technologies,
wouldn't be considered "public-facing." The final rendering of that
information in a browser, yes, but not the source code from which it is
rendered.
However, if a federal employee was a website developer and couldn't see the
source code, then either 1) get that employee better developer tools because
all source code should be readable in even a basic text editor, 2) train the
employee, or 3) find him another job.
Jonathan wrote: " In my opinion, if a tag has been deprecated there is
probably a reason, ... I would just omit it altogether."
I think we agree here. Omit the summary element and edit the table to
include that information where everyone can see it.
The Summary attribute never accomplished what it was originally intended to
do, was often misused, and has the potential of hiding critical information
from some audiences. Glad it's going away!
Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New schedule for classes and workshops coming in 2013.
From: Jonathan Metz
Date: Fri, Jun 07 2013 2:37PM
Subject: Re: summary or caption
← Previous message | Next message →
Bevi wrote:
"It's rare that I've found a table where certain information needs to be
given to AT-users and hidden from the rest of the the audience. As I've
reviewed way-too-many tables in my job, I've seen the summary tag misused
for information like this: "This table is compiled from data collected in
2010-2011… That's helpful information for everyone."
See, I think that would be redundant. I believe that a sighted user would
look at a table and be able to understand that the table represents data
collected in 2010-2011 if that’s what the table is structured to be. I’ve
viewed summaries as just that. At first glance, what does this table
represent? This provides a way for someone to just take a peek at a table
without having to go into too much detail about it.
"From what I've heard, current interpretation of Section 508 is that it
applies to public-facing information and internal information that federal
employees need to perform their jobs."
I think you’re getting caught up too much in the legality here. All I was
referring to was that there is one thing that is hidden from a group of
users, which is theoretically discriminatory against that group. But in
reality, it’s a frivolous situation. Besides, Section 508 applies to
people with disabilities, not people without disabilities.
Providing context for a table is the same as providing a means to skip
navigation. Users who don’t require AT can most likely glean what they
need to in both situations without the need to have someone explicitly
tell them that information.
"I think we agree here.”
Totally, but if someone wants to use the Summary, I disagree it’s at a
detriment to others.
From: Ryan E. Benson
Date: Sun, Jun 09 2013 10:20AM
Subject: Re: summary or caption
← Previous message | Next message →
Bevi said:
2. The <CAPTION> tag is visible to everyone, AT-users and sighted users. If
you have a caption, why do you need a summary, too?
It all depends on table complexity, and you could throw in context for
argument's sake. At work, tables are usually captioned as "Table 1: Number
of people with AIDS between Year X and Year Y." A summary could be: Number
of AIDS cases broken down by year, US state, and gender, as well as a total
per year. Yeah you can argue that could be assumed, or not too hard to
figure out, but why not make it clear as possible in case?
4. As an editor, I believe that a good table should have a title, subtitle,
caption, and column headers that adequately provide this information to
everyone whether they are using AT or not. This information is built into
the body of the table for everyone to see, regardless of the technology they
are using.
I have never seen a table with a valid subtitle. What I have seen is the
document labeling scheme, such as a "Table 1" in a H1, and "Number of
people with AIDS between Year X and Year Y" in a paragraph or a span. The
"number of ..." is not a sub title of that, so that implementation is
invalid in my view. Now if we did:
<caption>
<hx>Number of people with AIDS between Year X and Year Y.</hx>
<p>Number of AIDS cases broken down by year, US state, and gender, as well
as a total per year. Gathered by xxx</p>
</caption>
that would be fine in my book, and would agree that the summary is not
needed. In my experience content authors wanting to put that much
information in plain text is not often, even if it assists in universal
design. Then if we change from HTML, to PDF or MS Word, the game plan
changes.
--
Ryan E. Benson
On Fri, Jun 7, 2013 at 12:45 PM, Chagnon | PubCom < = EMAIL ADDRESS REMOVED = >wrote:
> Devi's advocate chiming in.
> "a JAWS, NVDA or any other user of a screen reader will benefit from a good
> table summary."
>
> 1. Why should ONLY screen reader users benefit from a good table summary?
> Shouldn't all users have access to the same information?
> Remember, "summary" is an attribute on the <TABLE> tag, and it is not
> visible to sighted users. If you put information in it that is not
> available
> elsewhere, you could end up with a reverse-discrimination lawsuit.
>
> 2. The <CAPTION> tag is visible to everyone, AT-users and sighted users. If
> you have a caption, why do you need a summary, too?
>
> 3. As an editor for many decades (as well as a programmer), I'd have to
> split semantic hairs to describe the difference between a table caption and
> a table summary, as they are defined in HTML/WCAG. Is this an example of
> WCAG tag bloat - that is, too many tags, rules, guidelines,
> whatever-you-want-to-call-them with a lot of overlap in functionality? Does
> the W3C and WAI need more editors to help them select better names/labels
> for these elements?
>
> 4. As an editor, I believe that a good table should have a title, subtitle,
> caption, and column headers that adequately provide this information to
> everyone whether they are using AT or not. This information is built into
> the body of the table for everyone to see, regardless of the technology
> they
> are using.
>
> So, if you're thinking that some tag will help people use the information
> in
> a table, stop. Instead, go hire a competent editor to write/edit a better
> table. Creating another tag, attribute, or other markup doesn't completely
> fix the problem because often the problem is a poorly written and edited
> table.
>
> -Bevi Chagnon
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - -
> www.PubCom.com - Trainers, Consultants, Designers, Developers.
> Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
> Accessibility.
> New schedule for classes and workshops coming in 2013.
>
>
From: Don Mauck
Date: Mon, Jun 10 2013 8:21AM
Subject: Re: summary or caption
← Previous message | Next message →
Well, we can only hope that developers can truly design tables that make sense. Considering that many developers don't even get or understand how to add correct row and column headings, how can we ever hope that they'll do tables that make sense to all and have a table caption that means anything.
From: Greg Gamble
Date: Mon, Jun 10 2013 9:37AM
Subject: Re: summary or caption
← Previous message | Next message →
" Considering that many developers don't even get or understand how to add correct row and column headings,"
As a developer I have a problem with that comment. Most developers do, but are under time constraints to get the information out there, and are not allowed to tweak it to be 100% accessible. You need to also consider that many CMS's output incorrect markup, that developers have no control over, and are not allowed to correct.
Not everyone cares about accessible websites. It costs time/money to do it right and not all shops care to spend the resources to do it right.
From: Don Mauck
Date: Mon, Jun 10 2013 9:56AM
Subject: Re: summary or caption
← Previous message | Next message →
That's my point, this is what we fight with on a daily bases.
From: Trafford, Logan
Date: Mon, Jun 10 2013 10:12AM
Subject: Re: summary or caption
← Previous message | Next message →
Well my personal experience over the last couple of years is the contrary. I have come across a significant number of developers with major software companies who have absolutely no clue about accessibility at all, let alone how to construct a proper table. I've spent the last couple of years mentoring a number of developers from various software companies that we have purchased products from, in order to better integrate their products into our existing systems (with WCAG standards in mind).
That being said, I do fully agree with the sentiment about the challenges of timelines and CMS markup. We ended up abandoning one CMS (after investing a substantial sum of money) because we simply couldn't manipulate the code to adhere to standards.
It is a slow process for sure, but convincing management to build in the extra time at the beginning of a project instead of the end of a project is the only way things are ever going to improve.
Logan Trafford
From: Ron Stewart
Date: Mon, Jun 10 2013 10:25AM
Subject: Re: summary or caption
← Previous message | Next message →
While not finding it surprising I do find it disturbing that in 2013 accessibility is still an afterthought, at best, on the minds of most developers and designers. What are you going to do when in short order websites are ruled to be places of public accommodation under the ADA. From a customer service and marketing perspective this wiliness on the part of management to deliberately exclude ~12% of the customer base would seem to me to be just bad business.
I do a lot of training and development around accessibility and find that the vast majority of designers are ignorant or just dismissive of the positive attributes of accessible design.
Ron Stewart
From: Chagnon | PubCom
Date: Mon, Jun 10 2013 12:28PM
Subject: Re: summary or caption
← Previous message | Next message →
I've spent my career focusing on how design affects behavior and response, whether I've been practicing architecture, publication design, media design, industrial/product design, or advertising/marketing design.
Our community is going to have to survey people and learn why they're not making accessible websites. What are their barriers? Once we know that, we can then develop solutions for them.
I've heard a lot of reasons from my students and clients about why they haven't fully deployed accessible websites. Understand, these are not my opinions but theirs, so don't flame me for relaying them!
One note: a large US government contractor is scheduling a 1-day overview class in web accessibility with my firm. It's for a handful of their top website managers who oversee the main websites of 2 federal agencies (these are huge websites, millions of pages each).
The "students" are accomplished web developers and they can't figure out what they need to do. They've visited W3C, WAI, WCAG, etc. and found that information so overwhelming and intimidating that they got stymied. This large corporation's top brains can't put together an action plan for getting the websites overhauled. So for them, it's not a question of money or time, it's more that they don't know what to do.
Other comments I've heard (my paraphrased and summarized versions):
1. I don't want my website to be boring and ugly. I want a visually attractive design for my website, and accessibility ruins my design.
2. Oh god, please don't make me read WCAG 2.0.
3. WCAG. ARIA. DAISY. Etc. When will it end? Why don't they give us just one set of rules to follow? I give up. I don't know what they want.
4. We use (choose one) Drupal, PhP, WordPress, Joomla, fill-in-the-blank CMS technology and it's not accessible. We need to use this technology to meet our publishing/information needs and can't do without it. We've spent thousands/millions of dollars developing the website and are not going to throw it out because a small group of people might have problems using it.
5. My boss (or top brass) won't fund the cost and time to make our site accessible.
6. My boss won't hire the extra staff or contractors I need to make the site accessible.
7. We get dozens of Word and PDF documents every day that we have to make accessible because our office staff doesn't know how to do that. I can't keep up with that work, let alone get accessibility built into the website itself. There are not enough hours in a day to get everything done.
8. Why spend all that time and money for 2% of my website's visitors? I'll wait for the lawsuit.
So with these comments in mind, what can we, the WebAIM community, do to remove these barriers to acceptance? (And yes, the term used in the marketing and psychology industries is "barrier to acceptance").
We know there's a problem. What can we do to remove the barriers and get the problem fixed?
From: ron
Date: Mon, Jun 10 2013 1:28PM
Subject: Re: summary or caption
← Previous message | Next message →
That is not an uncommon experience and under the law the Fed folks who contracted for those sites are in
direct violation unless these sites fall under the security/military exemptions or are congressional sites
which are exempted under the law.
The real issue is that no one is enforcing the law and actually never have since its inception. Case in point
look at what GSA has done with their 508 supports folks. Secondly the 508 revision is a case study in
government ineptitude or more likely governmental inertia. We look at WCAG 2.0 but more take a
functional usability perspective on things and have done so since the mid-90s.
That said I am very surprised that your folks have found conformance to be such a problem. My group
evaluates, trains and remediates sites working with developers and managers on a regular basis. We work
primarily in the educational space, but this can be more difficult than the corporate space. It is not that it
is difficult or confusing. In my experienced opinion it is more about priorities, and will, than the challenges
of the standards. No dedicated resources, no dedication to usability in general and the site ends up being
crap.
Well I better go catch my plane.
Ron Stewart
From: Greg Gamble
Date: Mon, Jun 10 2013 3:30PM
Subject: Re: summary or caption
← Previous message | Next message →
Maybe I'm naive, but can't you fudge the truth on what you say a working site is? Just tell a customer that the site is incomplete until accessible, so new sites will take longer and use more resources then ones that were created ten years ago. Most are clueless on what it takes to create a good site ... so don't say why ... blame the new browsers coming out or something similar.
To me it used to be anything that passed a validator was a finished site ... black and white, pass or fail. It's now become much more than that. There's a lot of gray around the edges nowadays, so it's not just about validating code, but validating the accessibility of the site too. So wouldn’t a completed site be an accessible one too?
From: Alan M. Dalton
Date: Tue, Jun 11 2013 3:56AM
Subject: Re: summary or caption
← Previous message | Next message →
That’s interesting, Bevi. I’ve spent years working in web accessibility—on
the other side of the world to you—and I’ve heard most of those same
reasons!
One approach that I’ve found useful is a short explanation of how to make
websites more accessible:
http://accessibility.ie/MakeYourWebsitesMoreAccessible . In my experience,
designers, developers, content providers, and managers benefit from:
- a short, plain-English summary of what WCAG 2.0 says, and what it applies
to;
- a short explanation and exercise to teach people how to structure
information as they write it;
- a fuller, plain-English guide to what WCAG 2.0 says about making audio
and video information accessible;
- a note about planning a project to include time for checking and
improving accessibility;
- advice about regular web accessibility audits;
- a template for web accessibility statements;
- a mention of content management systems;
- a mention of staff training and style guides.
Regards,
Alan.
Alan Dalton
- Accessibility Development Advisor http://accessibility.ie
- Access Officer http://tinyurl.com/NdaAccessOfficer
National Disability Authority http://www.nda.ie
25 Clyde Road, Dublin 4, Ireland http://goo.gl/maps/gOjcj
From: Chagnon | PubCom
Date: Tue, Jun 11 2013 8:24AM
Subject: Re: summary or caption
← Previous message | No next message
Alan, wow.
Your office has developed a fabulous website for pro-active change.
I especially admire the "plain English" guide and explanations, and the project planning guide.
Kudos.