Atom feeds and accessibility guidelines

[Pete Brunet <brunet@xxxxxxxxxx>]

Back in January there was a discussion
about accessibility guidelines.  Brian Smith suggested 3 alternatives:

1) The media could have alternatives
embedded
2) There could be n number of links
in the feed to alternatives.  That would require an extention to Atom
(which we shouldn't consider as a limitation for now).
3) Put alternative text in the atom:summary
field.

Brian felt option 1 was the best.  That
seems best to me as well (although the summary is also important to describe
the feed up front).  For embedded alternative media, would the MIME
type multipart/alternative be used?  

Some content files will have multimedia
capability, for example a SMIL file.  I assume that is handled with
the MIME type application/smil+xml and the feed reader would have to be
able to activate a SMIL player.

Are there any multimedia scenarios that
would be problematic?

Brian also brought up the case of providing
an alternative for a chart, i.e. providing a table containing the source
data such as providing HTML for the table.  I don't think that belongs
in a summary field.  It seems like link rel="alternate"
to an HTML file containing a table would be a good solution.  

For some images summary would be useful
if a short description would suffice.  If a longer textual description
is needed would link rel="alternate" to a textual file be the
right solution?

What should be done when you would like
to provide a short description via summary, a long textual description
via a link, and a HTML table via a link.  It appears that Atom has
the restriction of a single rel="alternate" link.  Perhaps
the HTML could contain both the long description and the table.

=== log of discussion on atom-syntax
mailing list from January ===

BS: I don't know of any. For media resources
(images, video), I would like some guidelines about how to provide accessible
alternatives. There are several possibilities already:

1. Many media file formats allow accessible
alternatives (descriptive text, captions, alternate audio tracks for non-sighted
users, transcripts) to be embedded directly in the media file.

2. An entry can provide use <atom:link
rel='alternate'> to link to accessible alternatives. This would probably
be most useful for media link entries or enclosures (any entry with non-textual
content, or out-of-line content). However, we might need separate HTML
alternatives for each disability (learning disabilities, vision impairment,
hearing impairment), but this isn't really allowed when using <atom:link
rel='alternative'>; See section 4.1.2. Due to that limitation, an alternative
link relation may be needed. Or, a set of link relations may be useful
that help guide users to the correct alternative based on their impairment.
For example, rel="large-print", rel="blind",
rel="deaf", rel="transcript",
rel="captioned".

3. Media link entries or enclosure entries
can provide accessible alternatives inline, possible using foreign markup.
For example, a media link entry for an image could include alternative
text for blind users in the <atom:summary> element. However, I think
this is bad practice, because it overloads the meaning of <atom:summary>,
but it is probably better than nothing. 

    JS: Actually, this is
one of the main reasons why atom:summary is provided.  If the atom:content
has binary content, or if it uses the src attribute, the atom:summary element
needs to be used to provide a human readable description. It definitely
is not bad practice.
    BS: Let's say that the
media resource is a chart. A reasonable summary might be "A rough
projection of annual sales, based on sales through July 17th. Contact your
department manager if you have questions." An (accessible) alternative
would be a HTML table with the data that was used for the chart. A feed
reader or editor is likely to provide only a limited amount of space for
the summary (see FeedDeamon for example), which makes viewing a table embedded
into the summary difficult. For a variety of reasons, summaries usually
need to be short, but accessible alternatives may not be compact. Plus,
atom:summary cannot be used to provide multiple accessible alternatives
for one resource, which is needed to handle different disabilities.

For those reasons, atom:summary should
be used only as a fallback when no accessible alternative is available.

Guidelines for choosing between these
mechanisms would be very useful. Also, a mechanism for detecting when accessible
alternatives might be out of date would be useful. For example, if somebody
updates a video, but didn't update the transcript, that is information
that would be helpful for a non-sighted user.

if I was blind, I would probably want
the ability to subscribe to a feed where the full content of the transcripts/alternative
text was inline, instead of linked to using <atom:link rel='transcript'/>.


Pete Brunet
                    
                     
                     
         
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
Ionosphere: WS4G