Subject: Atom feeds and accessibility guidelines

From: Pete Brunet <[email-masked]>
Date: Wed, 4 Jun 2008 23:49:53 -0500

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

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 4 Jun 2008 22:42:08 -0700

Pete,
 
I think that the solutions to these problems are probably best found
empirically based on feedback from people who need/prefer accessibility
enhancements to feeds. I was happy to provide some guesses as to what I
thought would work, but I don't have the resources to measure the
effectiveness of any solution. I am hoping that your team at IBM, or another
team with similar resources, will be able to provide some guidance to feed
publishers and tool creators based on usability testing by users with
disabilities. 
 
My guess is that multipart/alternative content would make things *less*
accessible today, not more accessible. My feed reader won't even display
entries that have multipart/alternative content and no tools (I know of)
will help users author entries as multipart/alternate. I also would guess
that users with disabilities would have the most success with (X)HTML
content that uses standard HTML accessibility features to enhance multimedia
that is embedded within it. In other words, Atom content should be marked up
pretty much the same way as a web page.
 
Accessibility for tasks like editing AtomPub media collections (which are
usually used to store multimedia content that is linked to from other
entries) probably depends mostly on the UI of the client. Whoever builds the
first accessible multimedia-publishing AtomPub client will probably set the
standards for accessibility based on their usability tests.
 
Regards,
Brian

---

From: "James Holderness" <[email-masked]>
Date: Thu, 5 Jun 2008 07:24:11 +0100

Peter Brunet:
> For embedded alternative media, would the MIME type 
> multipart/alternative be used?

multipart/* media types are not permitted in RFC4287.

Regards
James

---

From: Pete Brunet <[email-masked]>
Date: Thu, 12 Jun 2008 11:07:02 -0500

Thanks Brian.  My assessment so far is that there are no a11y holes in the 
spec for the feed syntax.  Regarding media I'd point authors at a document 
from NCAM (National Center for Accessible Multimedia), "Accessible Digital 
Media Design Guidelines for Electronic Publications, Multimedia and the 
Web" at http://ncam.wgbh.org/publications/adm/ and in particular, 
"Guideline H, Provide access to multimedia presentations for users with 
sensory disabilities." at 
http://ncam.wgbh.org/publications/adm/guideline_h.html.  Does that sound 
adequate?

If I create some guidelines, and I probably will, I can use refer to the 
NCAM document and I can use the list from James Snell at 
http://www.imc.org/atom-syntax/mail-archive/msg20349.html 

>From that list some of the a11y issues are already mandatory:

 1. Explicitly typed text - title's, summary's, subtitle's, rights,
    and content are all explicitly typed as either plain text, html,
    xhtml, xml or some other media type

 2. Required text content - title's are required for every entry and
    textual content in the form of either an atom:summary or
    atom:content element is required.  It is possible for either of
    these to be empty, but the elements themselves are required,
    allowing applications to know explicitly whether or not text
    content has been provided.

And some would need to be in the guidelines:

 3. Language tags - The use of xml:lang attributes allow the language
    for every piece of text to be explicitly declared.

 4. Link titles - The atom:link element has an optional
    language-sensitive title attribute that is a rough analog to the
    html img tag's alt attribute.

 5. Link href lang - The atom:link element specifies an hreflang
    attribute that identifies the language of the referenced resource.

 6. Link types - The atom:link element specifies a type attribute that
    identifies the media type of the referenced resource

 7. Accessible (x)html embedded in an atom text element or atom:content
    should continue to remain accessible within the Atom feed

Is there something about item 2 that should be mentioned in a guidelines 
document?

Regarding the AtomPub spec, is there is a list of accessibility features 
such as the list James provided?

I'm also interested what the community feels are the accessibility 
advantages of AtomPub over the RSS equivalent(s).

Pete Brunet

"Brian Smith" <[email-masked]> 
Sent by: [email-masked]
06/05/2008 12:42 AM

To
Pete Brunet/Austin/IBM@IBMUS, <[email-masked]>
cc

Subject
RE: Atom feeds and accessibility guidelines

Pete,
 
I think that the solutions to these problems are probably best found 
empirically based on feedback from people who need/prefer accessibility 
enhancements to feeds. I was happy to provide some guesses as to what I 
thought would work, but I don't have the resources to measure the 
effectiveness of any solution. I am hoping that your team at IBM, or 
another team with similar resources, will be able to provide some guidance 
to feed publishers and tool creators based on usability testing by users 
with disabilities. 
 
My guess is that multipart/alternative content would make things *less* 
accessible today, not more accessible. My feed reader won't even display 
entries that have multipart/alternative content and no tools (I know of) 
will help users author entries as multipart/alternate. I also would guess 
that users with disabilities would have the most success with (X)HTML 
content that uses standard HTML accessibility features to enhance 
multimedia that is embedded within it. In other words, Atom content should 
be marked up pretty much the same way as a web page.
 
Accessibility for tasks like editing AtomPub media collections (which are 
usually used to store multimedia content that is linked to from other 
entries) probably depends mostly on the UI of the client. Whoever builds 
the first accessible multimedia-publishing AtomPub client will probably 
set the standards for accessibility based on their usability tests.
 
Regards,
Brian

---

From: Bill de hOra <[email-masked]>
Date: Thu, 12 Jun 2008 19:12:08 +0100

> advantages of AtomPub over the RSS equivalent(s).

Assuming you mean RFC5023, here's one. Every time you post to an AtomPub 
server you get a link back and not just an ok. This means you can drive 
basic follow-on action via links, such as "view your comment". This 
can't be done in a number of proprietary posting systems I've seen. 
Having hypertext links at every publishing step is a fundamentally good 
feature, and not just for accessibility.

Bill