[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Atom feeds and accessibility guidelines

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