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
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,
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
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).
IBM Accessibility Architecture and Development
11501 Burnet Road, MS 9022E004, Austin, TX 78758
Voice: (512) 838-4594, Cell: (512) 689-4155
<brian@xxxxxxxxxxxxxx> Sent by: owner-atom-syntax@xxxxxxxxxxxx
06/05/2008 12:42 AM
Pete Brunet/Austin/IBM@IBMUS, <atom-syntax@xxxxxxx>
RE: Atom feeds and accessibility guidelines
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.