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
