Brian Smith wrote:
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.
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.
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.
Interesting idea.
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.
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
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
