E-mail List Archives
Thread: placement for legend associated with a table
Number of posts in this thread: 2 (In chronological order)
From: Angela French
Date: Tue, Sep 29 2015 9:24AM
Subject: placement for legend associated with a table
No previous message | Next message →
We have a table that has five different table headers with acronyms in them. We want to supply a legend/key that spells out the acronyms. I don't believe I've ever seen this topic or question come up - but is there a preferred method of presentation for such a legend/key that support accessibility/usability by people who use screen readers? Wondering if it might even go in a summary. Below is the information that would be in the legend:
* ABE Adult Basic Education
* ESL English as a Second Language
* EL/C English Literacy and Civics Education
* HSE High School Equivalency
* HS21+ High School 21-Plus
Thank you,
Angela French
Internet Specialist
Washington State Board for Community and Technical Colleges
360-704-4316
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
www.checkoutacollege.com<;http://www.checkoutacollege.com/>;
www.sbctc.edu<;http://www.sbctc.edu/>;
From: Chagnon | PubCom.com
Date: Tue, Sep 29 2015 9:46AM
Subject: Re: placement for legend associated with a table
← Previous message | No next message
Our firm developed an overall guideline that I think would help in your case, Angela.
Combining our associates' immense experience in all realms of publishing (academic, government, STEM, commercial periodicals, advertising/PR), we put together our best theories of communication. We believe that when possible, it's best to put "guidance" about the item in front (or before) it.
Our template for tables, figures, and other complex data:
1) Figure/Table Number: Figure/Table Title.
2) Prefatory information (includes keys like yours, info that WCAG defines as a summary, and traditional info like "In thousands of dollars, 2010â2015." It can be as long or short as you need it to be.)
3) The Figure/Table itself.
We do not like WCAG summaries because they are extremely time-consuming to create in PDFs and in the common authoring programs (Word, PowerPoint, and InDesign). We're aiming to make accessible documents as easy as possible to produce by authors, designers, and developers; therefore, anything that can't be done directly in Word, PowerPoint, and InDesign is avoided. I don't want my staff spending any more time than necessary in Acrobat fixing broken, inaccessible PDFs.
Human behavior research has shown that preparing the reader for what they are about to read always produces better comprehension and understanding. And this theory helps all readers, not just those using AT.
Hope this helps,
âBevi Chagnon