Subject: Atom and accessibility

From: Pete Brunet <[email-masked]>
Date: Mon, 28 Jan 2008 19:43:08 -0600

I am interesting in evaluating Atom to determine what the accessibility 
needs are.  I'd limit this, at least for now, to enhancements to help 
blind screen reader users.  I'd like to eventually develop a list of 
recommendations for improvement, e.g development of new technology or 
creating usage guidelines.  My primary interest is in relation to the use 
of Atom in mashups, for example, a web page may start out being accessible 
by using W3C WCAG ( Web content Accessibility Guidelines, see 
http://www.w3.org/TR/WAI-WEBCONTENT/ ) but by incorporating content via 
Atom it may become inaccessible.  If you've done any research in this area 
or if you have pointers to background material I'd like to hear from you. 
I am starting at ground zero with respect to Atom (but have been in the 
accessibility field for many years) so it's likely that no information 
will be too basic :-) 

Should further discussion related to accessibility take place on this list 
or atom-protocol?

Thanks, 
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: James M Snell <[email-masked]>
Date: Mon, 28 Jan 2008 21:26:26 -0800

Hey Pete,

Glad to see this :-). There are several features of Atom that have been 
designed with accessibility in mind.

  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.

  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.

There are a number of areas where accessibility is somewhat inadequate:

  1. The atom:icon and atom:logo elements do not have title or type
     attributes.

  2. Despite requirements for the use of atom:title, atom:summary and
     atom:content, it is possible for an entry to contain zero
     human-readable text

It would be helpful if someone with a strong accessibility background 
could run some tests on a corpus of atom feeds to see what accessibility 
issues appear to be most common.  As far as I am aware, no such analysis 
has ever been done.

- James

Pete Brunet wrote:
> creating usage guidelines.  My primary interest is in relation to the 
> use of Atom in mashups, for example, a web page may start out being 
> accessible by using W3C WCAG ( Web content Accessibility Guidelines, see 
> Atom it may become inaccessible.  If you've done any research in this 
> area or if you have pointers to background material I'd like to hear 
> from you.  I am starting at ground zero with respect to Atom (but have 
> been in the accessibility field for many years) so it's likely that no 
> information will be too basic :-)  
> 
> Should further discussion related to accessibility take place on this 
> list or atom-protocol?
> 
> Thanks,
> *Pete Brunet*
>

---

From: Pete Brunet <[email-masked]>
Date: Tue, 29 Jan 2008 09:18:12 -0600

Thanks James, That's great input.  I might be able to find someone to do 
the testing.  Is there a corpus available that could be used?  Regarding 
the two inadequacies you mentioned

attributes.

Is that being considered for a future version of Atom?

> 2. Despite requirements for the use of atom:title, atom:summary and 
atom:content, it is possible for an entry to contain zero human-readable 
text

Has anyone written (or started to write) accessibility guidelines?

Pete Brunet

James M Snell <[email-masked]> 
Sent by: [email-masked]
01/28/2008 11:26 PM

To
Pete Brunet/Austin/IBM@IBMUS
cc
[email-masked]
Subject
Re: Atom and accessibility

Hey Pete,

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 29 Jan 2008 07:42:14 -0800

> Is that being considered for a future version of Atom?

There are no future versions of Atom being considered :-).  It would be 
possible to add the attributes as an extension, or to define alternative 
icon/logo link relations so the link's element type and title can be used.

> Has anyone written (or started to write) accessibility guidelines?

Not that I am aware of.  I, for one, would welcome such guidelines and 
would be willing to help write them up.

- James

> *James M Snell <[email-masked]>*

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 29 Jan 2008 08:08:35 -0800

Pete Brunet wrote:
> James Snell wrote:
attributes. 
> Is that being considered for a future version of Atom? 

1. <atom:title> and <atom:subtitle> could be considered the accessible
alternative for the icon and logo. Most modern accessibility guidelines
recommend against providing alternative text for logos and icons when
that alternative text would significantly duplicate content available
elsewhere in the document.

A title attribute is a bad idea because human-readable text shouldn't be
represented with attributes. If it is needed then it should be a text
construct. 

> > 2. Despite requirements for the use of atom:title, atom:summary and
atom:content,
> > it is possible for an entry to contain zero human-readable text 

That is true, but now there are Atom applications where entries are
meant to be consumed only by software. An example is
http://ietfreport.isoc.org/idref/draft-nottingham-http-cache-channels/.
An annotation that indicates "this is not intended to be read by people"
would be an accessibility improvement for such documents.
	
> Has anyone written (or started to write) accessibility guidelines? 

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. 

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'/>. 

- Brian

---

From: James M Snell <[email-masked]>
Date: Tue, 29 Jan 2008 08:40:03 -0800

> represented with attributes. If it is needed then it should be a text

True, however, while unlikely, the title and summary can each contain 
complex markup.  If accessibility guidelines were to suggest using those 
elements as the alternate text for the icon/logo, then the guidelines 
would need to suggest appropriate content restrictions for each or else 
specify a processing model so markup can be dealt with appropriately.

> would be an accessibility improvement for such documents.

Interesting idea.

> because it overloads the meaning of <atom:summary>, but it is probably

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.

- James

---

From: Pete Brunet <[email-masked]>
Date: Tue, 29 Jan 2008 10:52:51 -0600

> I might be able to find someone to do the testing.  Is there a corpus 
available that could be used?
Since James didn't answer this - does anyone else have suggestions for a 
corpus?

> It would be possible to add the attributes as an extension, or to define 
alternative icon/logo link relations so the link's element type and title 
can be used.
Is this a issue that would best be explored in atom-protocol?

Pete Brunet

01/29/2008 09:42 AM

To

- James

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 29 Jan 2008 09:05:12 -0800

James M Snell wrote:
> True, however, while unlikely, the title and summary can each 
> contain complex markup.  If accessibility guidelines were to 
> suggest using those elements as the alternate text for the 
> icon/logo, then the guidelines would need to suggest 
> appropriate content restrictions for each or else specify a 
> processing model so markup can be dealt with appropriately.

Right. Restrictions on titles and summaries are needed even for users
without disabilities, like we discussed a while back when we were
debating whether Atom processors should support HTML/XHTML content in
titles. 

> > 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.
> 
>   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.

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.

- Brian

---

From: James M Snell <[email-masked]>
Date: Tue, 29 Jan 2008 09:14:34 -0800

> Since James didn't answer this - does anyone else have suggestions for a 

...didn't answered it yet :-)  There are quite a few atom feeds 
available.  One immediate resource that is readily available to you 
would be any of the 100k+ feeds published by the ibm internal blog server.

>  > It would be possible to add the attributes as an extension, or to 
> define alternative icon/logo link relations so the link's element type 
> and title can be used.

No, here is better.

- James