LISTSERV mailing list manager LISTSERV 16.0

Help for EAD Archives


EAD Archives

EAD Archives


EAD@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

EAD Home

EAD Home

EAD  June 2013

EAD June 2013

Subject:

Re: finding aid HTML and accessibility

From:

"Custer, Mark" <[log in to unmask]>

Reply-To:

Encoded Archival Description List <[log in to unmask]>

Date:

Tue, 18 Jun 2013 14:21:52 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (73 lines)

As a follow-up to this thread, I just wanted to say that this is *exactly* the sort of task that some folks might want to undertake during a breakout session at this year's EAD Hackathon (and throughout the rest of the conference, as well as long after).  As Michele rightly points out, it's not just an issue of outputting EAD into an HTML output that's usable for a variety of assistive technologies, it's also a matter of figuring out how best to structure (or re-structure) that description in a variety of contexts (e.g. preserving the hierarchy and its meaning).  

Since there are pre-existing groups that address these issues, like the Boston Accessibility Group (http://www.a11ybos.org/), it's not like anyone would have to start from scratch while considering how to improve EAD-to-HTML accessibility practices and getting that information into a sharable set of standards.  And, as luck would have it, the Boston Accessibility Group will be having their annual (free!) conference, in Cambridge, shortly after SAA, so that might be the perfect time and place to continue the conversation with a variety of experts on the subject.

Just a thought,

Mark

P.S.  Since Michele's message (as well as a similar one that was sent to EAD RT listserv last year) got me searching for tips and updates about web accessibility practices, I thought that I'd share the following online resources that I'm finding to be really helpful:

http://www.clarissapeterson.com/2012/11/html5-accessibility/ 
http://jfciii.com/presentations/wasp/accessibility.html 
https://github.com/klamping/html5tx-a11y/





-----Original Message-----
From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf Of Michele R Combs
Sent: Monday, June 10, 2013 12:52 PM
To: [log in to unmask]
Subject: finding aid HTML and accessibility

Hello, collective wisdom --

I'm wondering what approaches people have taken to encoding finding aids for browser display in a manner that is useful to folks who access web pages through non-visual means (e.g., a screen reader).  I know that HTML tables (a) aren't supposed to be used for layout and (b) can pose problems for people using alternate means to "read" web pages, and the hierarchical nature of finding aid descriptions poses a sort of extra level of problem.

Given this sort of data:

Box	Folder	Contents
		Memorabilia
1	1		Awards
1	2		Citations
			Photographs
2	1			Family
2	2			Friends
2	3			Travel
2	4		Scrapbooks

how does one create HTML that is both good HTML and non-visually accessible/meaningful?

Here are the approaches I've thought of so far:

FIRST:  One could encode the entire box/folder listing as a simple 3-column table, with the columns being "box" "folder" and "contents." I could then assign a @class attribute to each <td> (e.g., class="level1" class="level2") and use CSS to indent "Awards" "Citations" "Friends" etc. to the appropriate level for the visual folks.  Technically this is probably the most correct in terms of HTML, since the data does consist only of three types: box, folder, and contents.  But would the class attribute be any use to the non-visual folks?  Is it recognized by screen readers, and would it be enough to convey the hierarchical information in a useful manner?

SECOND:  One could do it as a multi-column table, putting the different levels into different columns (in the example above I'd need five columns: box, folder, c01, c02, c03) and spanning as necessary.  That (sort of) preserves the hierarchical nature of the information but it means there will be a bunch of extra columns, and I feel like this is using the table more for layout purposes than for actual tabular data.  Plus web-readers don't always do well with spanned columns - might just be a big mess -- and big tables can be slow to load in general.

THIRD: One could use separate tables for each set/subset of boxes/folders, and include the full hierarchy as the table caption, e.g.:

<p>Memorabilia</p>
<table><caption>Memorabilia</caption>[box/folder list]</table>