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

RE: Atom feeds and accessibility guidelines




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
                                                                         

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



"Brian Smith" <brian@xxxxxxxxxxxxxx>
Sent by: owner-atom-syntax@xxxxxxxxxxxx

06/05/2008 12:42 AM

To
Pete Brunet/Austin/IBM@IBMUS, <atom-syntax@xxxxxxx>
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