Pete Brunet wrote: > James Snell wrote: > > 1. The atom:icon and atom:logo elements do not have title or type 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
