Subject: Atom and accessibility - Atom vs RSS

From: Pete Brunet <[email-masked]>
Date: Fri, 6 Jun 2008 11:20:09 -0500

What a11y features does Atom have that RSS doesn't?

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

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,

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:
> 
> 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: Fri, 06 Jun 2008 09:43:25 -0700

There are several challenges with RSS a11y.  The most important is that 
there is significant ambiguity in the RSS content model that makes it 
difficult (at best) for software to determine automatically whether an 
entry contains markup or plain text.  Content is not explicitly labeled 
in RSS like it is in Atom.

- James

Pete Brunet wrote:
> *James M Snell <[email-masked]>*

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Fri, 6 Jun 2008 19:10:47 +0200

> What a11y features does Atom have that RSS doesn't?

Besides the content model, there is also the fact that RSS has no
summary/content dichotomy, which allows Atom to transport non-
human-readable data (as the content) along with a human-readable
alternative form (in the summary). Although you can include
multiple kinds of payload elements in RSS (eg. include both a
description and content:encoded), all of them have are specified
in isolation, so there are no precedence rules to decide which
element’s content to use in which context.

Furthermore, several RSS elements, such as title, may not contain
markup per the spec, and therefore cannot contain such things as
ruby annotations.

Those are the ones that occur to me off the top of my head.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "James Holderness" <[email-masked]>
Date: Fri, 6 Jun 2008 20:20:16 +0100

Aristotle Pagaltzis wrote:
> alternative form (in the summary).

That sounds great in theory, but in practice you're usually way better off 
with something like this:

<content type="html">
  &lt;img src="boat.jpg" alt="picture of a boat" /&gt;
</content>

Than you are with something like this:

<summary>picture of a boat</summary>
<content type="image/jpeg" src="boat.jpg"/>

That doesn't apply to all forms of content of course, but if there's an 
accessible way to represent your data in HTML, then an HTML content element 
is probably the most interoperable way to syndicate it.

> markup per the spec, and therefore cannot contain such things as

Out of curiosity, do you know of any Atom feed readers that support ruby 
annotations in titles?

Regards
James

---

From: James M Snell <[email-masked]>
Date: Fri, 06 Jun 2008 13:04:18 -0700

While the current limitations of existing readers is important to 
consider, it's also important to note that the standard supports 
capabilities that go well beyond what those current readers have chosen 
to implement, especially given that most of those readers began life as 
RSS readers.

- James

James Holderness wrote:
> That sounds great in theory, but in practice you're usually way better 
> off with something like this:
> 
> <content type="html">
> accessible way to represent your data in HTML, then an HTML content 
> element is probably the most interoperable way to syndicate it.
>

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Fri, 6 Jun 2008 22:51:06 +0200

* James Holderness <[email-masked]> [2008-06-06 21:35]:
> That sounds great in theory, but in practice you're usually way
> better off with something like this:

As a publisher, yes. For authors of clients, particularly clients
intended for a specific purpose, the extent to which other
existing clients fail to take advantage of the specified features
of the format is of little relevance.

> That doesn't apply to all forms of content of course

Which is the point. In the cases where it doesn’t apply, RSS
offers no way to do it at all. Atom does.

> Out of curiosity, do you know of any Atom feed readers that
> support ruby annotations in titles?

No, but I would not be surprised if some web-based aggregator or
other passes titles through with markup intact, or could easily
do so by adding the ruby markup elements to a whitelist.

Also, as long as major clients do not misinterpret the markup in
harmful ways and I had some content to publish that was already
annotated, I would include the markup anyway – certainly easier
for me than going to the effort of scrubbing them, and it gives
serendipity a chance. Staying on the beaten path even when the
risk of straying a little is minor is no way to make progress…

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Fri, 6 Jun 2008 23:59:22 +0100

> of the format is of little relevance.

But it *is* relevant - that was my point. It's not much good a feed 
publisher using some esoteric feature of Atom to make an image feed more 
accessible to blind users, if at the same time it makes those images 
invisible to the vast majority of sighted users!

I don't meant to imply that there aren't any features of Atom that would be 
useful for accessibility. I just think publishers need to be careful how 
they approach this sort of problem. When reading that the Atom *format* is 
capable of doing X, Y and Z, it's easy to jump to the conclusion that Atom 
*clients* will also automatically support X, Y and Z. That's often not the 
case.

> offers no way to do it at all. Atom does.

I'm not convinced of that. For example, that DOAP feed you posted a while 
could just as easily be implemented in RSS by embedding a doap:Project block 
as a child of the item element with a description element for the summary.

The advantage of Atom is that it makes content like that somewhat easier to 
surface via a feed processing API, but ultimately you're still probably 
going to be writing a custom processor to handle the data. There's not much 
that you just get for free.

> do so by adding the ruby markup elements to a whitelist.

I would be surprised, which is why I was asking. I'm almost sure most of the 
major online aggregators (google reader, bloglines, newsgator) strip markup.

> annotated, I would include the markup anyway

I definitely agree with you there. Although feed readers have not had a very 
good track record when it comes to dealing with markup in the past, I 
suspect you're pretty safe with most major clients these days.

Of course there's always the option of using Unicode interlinear annotation 
characters when markup is not an option. However, I suspect that's even less 
likely to be supported than ruby markup, and at least the markup has a 
decent fallback.

Regards
James

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Sat, 7 Jun 2008 05:03:00 +0200

* James Holderness <[email-masked]> [2008-06-07 01:10]:
>> As a publisher, yes. For authors of clients, particularly
                        ^^^^^^^^^^^^^^^^^^^^^^
>> clients intended for a specific purpose, the extent to which
>> other existing clients fail to take advantage of the specified
>> features of the format is of little relevance.
>
> But it *is* relevant - that was my point. It's not much good a
> feed publisher
       ^^^^^^^^^

Did you read what I wrote? :-)

> I'm not convinced of that. For example, that DOAP feed you
> posted a while could just as easily be implemented in RSS by
> embedding a doap:Project block as a child of the item element
> with a description element for the summary.
>
> The advantage of Atom is that it makes content like that
> somewhat easier to surface via a feed processing API, but
> ultimately you're still probably going to be writing a custom
> processor to handle the data. There's not much that you just
> get for free.

You get a MIME type. You can do what mail clients do. That’s a
lot for free.

With RSS, all you get is a namespace URI. How useful.

(No client actually takes advantage of this, of course, which
I find baffling in the extreme. The only plausible explanation
I can see is RSS blinders.)

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Sat, 7 Jun 2008 12:44:59 +0100

>>> As a publisher, yes. For authors of clients, particularly

Yeah, I realised how idiotic my response was *after* I posted it, but by 
that point I was too tired out by my rant to post a followup. :)

What I should have said was that it's something of a chicken and egg 
situation. There's not much incentive for clients to support features of 
Atom that aren't actually used by anyone. And feed publishers are not going 
to start using the features when they are so poorly supported by clients 
(especially when using such a feature would have a negative impact on 
readers).

Now, as you've said, there are certain things that may be worth doing (from 
both a client and server point of view) even if they're not supported, as 
long as doing so is not actively harmful. But I've been burned by this 
before (on the client side) - I regret supporting remote image content, 
given that the only feeds I've seen using it actually work better in 
aggregators that ignore that content.

> With RSS, all you get is a namespace URI. How useful.

Funny you should mention that. When I was looking at that DOAP example from 
earlier I was just thinking how useless the MIME type was, and how the only 
way you could interpret that content usefully was by looking at the 
namespace. :) In general you might have a point though.

To a large extent it depends on how clients are expected to treat this kind 
of content. Atom could really have used some guidance for implementors in 
this area IMHO. If you look at the mail specs (in particular the MIME 
stuff), they're actually quite explicit about what implementors should do 
(without be overly stringent).

For example, look at the following example atom entries (some elements 
omitted that aren't relevent to the discussion).

<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<content type="html">&lt;img src="eiffeltower.jpg"/&gt;</content>
</entry>

<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<content type="image/jpeg">
/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9...
</content>
</entry>

<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<content type="image/jpeg" src="eiffeltower.jpg" />
</entry>

<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<link rel="alternate" type="image/jpeg" href="eiffeltower.jpg" />
</entry>

<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<link rel="enclosure" type="image/jpeg" href="eiffeltower.jpg" />
</entry>

What exactly is the difference between each of them? Assuming a client is 
capable of displaying jpeg images, what *should* it do with each of those 
entries? Assuming it *wasn't* capable of displaying images, what should it 
do with them? Is the latter case different for a client that doesn't display 
images for accessibility reasons?

As a client author I really would like to know the answers to these 
questions. It's all very well not wanting to constrain implementations, but 
if you don't explicitly tell developers what to do, they tend to do nothing; 
or they all do something different. Either way publishers have no way of 
knowing what they're going to get, so they tend to stick with the tried and 
trusted html, even if another choice may have been more appropriate.

Regards
James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sat, 07 Jun 2008 14:39:44 +0200

> What a11y features does Atom have that RSS doesn't?

Personally, I prefer Atom because I find it to be more context free than 
RSS. Even though Atom rose from blogging requirements the format was 
cleverly defined so that those requirements don't prevent it to be used 
elsewhere. Sure it's XML and you can stuff anything you want in any 
format you like. But it feels less clumsy and more natural with Atom 
than RSS whenever you're not in a blog context. Aristotle mentioned the 
seperation between atom:summary and atom:content as one key of the power 
of Atom, to me atom:link and atom:category elements are even more 
interesting considering how simple yet powerful they are.

Overall I find Atom to dictate less the way I want things to be 
represented than with RSS. Could be a matter of taste but Atom feels 
more neutral and therefore easier to adapt.

- Sylvain

---

From: "Lindsley Brett-ABL001" <[email-masked]>
Date: Sat, 7 Jun 2008 14:19:38 -0400

Has any work been done on machine readable digital rights for Atom? I am
looking for something along the lines of ODRL. I noted a few passing
comments on it (while Googling) but nothing that seems to have taken
shape.

Brett Lindsley
Motorola Labs, Application Research Lab

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Sat, 7 Jun 2008 20:41:33 +0200

* Lindsley Brett-ABL001 <[email-masked]> [2008-06-07 20:30]:
> Has any work been done on machine readable digital rights for
> Atom?

There’s RFC 4946. That doesn’t make licences machine-readble of
course, but I think that concern is orthogonal to Atom anyway.

Regards,

---

From: "Lindsley Brett-ABL001" <[email-masked]>
Date: Sat, 7 Jun 2008 20:02:15 -0400

I'm looking for something similar to the OMA mobile profile of ODRL. The rights could indicate the linked content may be played for 3 days, played only twice, etc. This capability would require embedding the rules in the entry and signing it. It also requires trusted agents on the consumption side as well...

Brett

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aristotle Pagaltzis
Sent: Saturday, June 07, 2008 1:42 PM
To: [email-masked]
Subject: Re: Machine Readable Rights For Atom

> Has any work been done on machine readable digital rights for

There's RFC 4946. That doesn't make licences machine-readble of
course, but I think that concern is orthogonal to Atom anyway.

Regards,

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Wed, 18 Jun 2008 11:21:31 +0200

* James Holderness <[email-masked]> [2008-06-07 13:55]:
> Funny you should mention that. When I was looking at that DOAP
> example from earlier I was just thinking how useless the MIME
> type was, and how the only way you could interpret that content
> usefully was by looking at the namespace. :) In general you
> might have a point though.

This is a problem with RDF in general. That DOAP-over-Atom is the
only easily visible example of non-HTML content in feeds (that I
know of anyway) is unfortunate in that respect. The point is, if
someone shipped PDFs via a feed, say, then a client has all the
information and the system mechanisms it needs to do something
useful with that content.

> Atom could really have used some guidance for implementors in
> this area IMHO. If you look at the mail specs (in particular
> the MIME stuff), they're actually quite explicit about what
> implementors should do (without be overly stringent).

Completely agreed. Shades of an implementor’s guide…

> For example, look at the following example atom entries (some
> elements omitted that aren't relevent to the discussion).
>
#1
> <content type="html">&lt;img src="eiffeltower.jpg"/&gt;</content>
#2
> /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9...
#3
> <content type="image/jpeg" src="eiffeltower.jpg" />
#4
> <link rel="alternate" type="image/jpeg" href="eiffeltower.jpg" />
#5
> What exactly is the difference between each of them? Assuming a
> client is capable of displaying jpeg images, what *should* it
> do with each of those entries? Assuming it *wasn't* capable of
> displaying images, what should it do with them? Is the latter
> case different for a client that doesn't display images for
> accessibility reasons?

In #1 the content is HTML. The summary semantically is not
alternative content for the image, it is for the HTML content
as a whole, which might consist of more than just an image and
in this case just happens not to. Any fallback for the image in
non-image-capable aggregators would have to happen at the HTML
level, ie with an `alt` attribute.

Entries #2 and #3 are identical: the content is an image, so the
summary applies to the image specifically. The image should be
shown in contexts where the full content is shown, and if it
cannot be, then the summary should stand in.

In case #4 I would expect an aggregator to show just the summary
along with a link to the image. Some aggregators that allow
loading the permalink page when you click on an item, instead of
showing in the in-feed content; those would probably try to load
the image, in which case they would treat it just like a browser.

With #5 I would expect the summary to be shown, with the image
downloaded to some directory of the user’s choosing if the user
has so configured their reader, and some kind of attachment
feature to be provided for viewing the downloaded content.

Regards,

---

From: Pete Brunet <[email-masked]>
Date: Wed, 25 Jun 2008 20:35:22 -0500

Thanks James,

>There are several challenges with RSS a11y.
Besides the content labeling problem you mention, what are the others?

>Content is not explicitly labeled in RSS like it is in Atom.
Are you referring to the type attribute?

Pete Brunet

06/06/2008 11:43 AM

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

- James

---

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

>From Aristotle Pagaltzis on 06/18/2008 04:21 AM

<AS>
#4
#5

With #5 I would expect the summary to be shown, with the image
downloaded to some directory of the user?s choosing if the user
has so configured their reader, and some kind of attachment
feature to be provided for viewing the downloaded content.
</AS>

1) What is expected in this additional case?

<entry>
<summary>A photograph of the Eiffel Tower.</summary>
<link rel="related" type="image/jpeg" href="eiffeltower.jpg" />
</entry>

2) Is it expected that enclosures are to be downloaded along with the feed 
at the time the reader fetches the feed?  Do readers ever just expose the 
link and fetch the enclosure later upon demand by the user, as in case #4?

3) In the cases where links are displayed what is used for the link text?

4) I agree that guidelines are needed.

Pete Brunet

---

From: Ernest Prabhakar <[email-masked]>
Date: Thu, 26 Jun 2008 10:55:30 -0700

Hi Pete,

On Jun 26, 2008, at 10:12 AM, Pete Brunet wrote:
> 2) Is it expected that enclosures are to be downloaded along with  
> the feed at the time the reader fetches the feed?  Do readers ever  
> just expose the link and fetch the enclosure later upon demand by  
> the user, as in case #4?

My understanding is that enclosure is *by definition* something that  
should be pre-fetched, as opposed to ordinary links which are  
dereferenced when clicked by the user.  For readers that are web  
browsers, I think that distinction is usually observed.

-enp

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Thu, 26 Jun 2008 20:08:25 +0200

> <link rel="related" type="image/jpeg" href="eiffeltower.jpg" />

That’s just a summary along with an auxiliary link, and that’s
how I would expect them to be shown.

> 2) Is it expected that enclosures are to be downloaded along
> with the feed at the time the reader fetches the feed? Do
> readers ever just expose the link and fetch the enclosure later
> upon demand by the user, as in case #4?

Yes to both questions. User agents are always free to do whatever
they want.

The purpose of the enclosure relation is so that a publisher can
say “this is a potentially large blob of multimedia data that
subscribers will probably want to consume in some sort of
off-screen/off-line setting” (such as the many people that listen
to podcasts during commutes). This is much more to do with human
than technical factors; in general, the publisher sets up the
expectation for subcribers that periodically produced blobs of
multimedia will be advertised using this feed. The `enclosure`
relation is just the technical signal by which allows tools to
support this use case.

> 3) In the cases where links are displayed what is used for the

The obvious first candidate is `atom:link`’s `title` attribute.
In general I would expect the `href` to be shown in absence of a
title, although there are exceptions. F.ex. in the case of
`alternate` links, `atom:link/@title` is redundant.

Regards,

---

From: Pete Brunet <[email-masked]>
Date: Sat, 28 Jun 2008 15:04:59 -0500

>From Sylvain Hellegouarch on June 07:

>atom:link and atom:category elements are even more interesting

Thanks Sylvain, How does that help accessibility?

Pete Brunet

---

From: Pete Brunet <[email-masked]>
Date: Sat, 28 Jun 2008 18:55:37 -0500

difficult (at best) for software to determine automatically whether an 
entry contains markup or plain text.

I'd like to include this information in an Atom accessibility guideline 
but I need some more detail to help me undertand the issue.

Pete Brunet