Re: feedback requested on WAI CG Consensus Resolutions on Text alternatives in HTML 5 document

On 15/08/2009 15:17, William Loughborough wrote:
> There are a few attributes that require the author to actually write
> in native language rather than code/script. Among these are: alt,
> longdesc, summary, caption. I am so scattered that I can't come up
> with a complete list


 > Perhaps if we gathered them, it would help address their peculiar
 > place in designing the markup language to make them most effective?

I'm not sure what the value of looking only at attributes is, since 
element content seems equally relevant to text labels, alternatives, and 
descriptions (e.g. the contents of "legend", the "label" element, 
"caption", "details", "canvas", or "object"). Moreover, elements make 
for more accessible text, since you can indicate changes of language 
and, in the case of text alternatives ("canvas" and "object"), you can 
include equivalents to functionality available in the non-text version.

But in case a list of such attributes helps, here's mine.

"caption" expects human-friendly content, but it is an element not an 
attribute, so we can exclude that.

"longdesc" accepts only a URI, so we can exclude that.

text/html attributes that expect human-friendly text are:

    * "content" (for certain uses of the "meta" element, such as "meta 
name='description'", though not for others)
    * "title"
    * "value" (for "input type='submit'" and input type='button'")
    * "prompt" (for "isindex", not conforming in the HTML5 editor's draft)
    * "placeholder"
    * "label" (for "option")
    * "alt"
    * "aria-label" (not /yet/ conforming to any standard, but likely to 
become so)
    * "summary" (not conforming in the HTML5 editor's draft)
    * "abbr" (not conforming in the HTML5 editor's draft)
    * "axis" (not conforming in the HTML5 editor's draft)
    * "contexthelp" (proprietary to Freedom Scientific's AT software, 
not conforming in any HTML standard or in the HTML5 editor's draft, for 
details see )

> In most (all?) cases these attributes are in the service of
> describing what is inaccessibly depicted in Web materials

Depends on exactly what subset you look at, and how you look at that subset.

If you mean "inaccessibly" as in so that "people with disabilities" 
could not "perceive, understand, navigate, and interact with the Web, 
and that they" could not "contribute to the Web" (WAI's definition), 
then many of these attributes were intended to help remedy that.

But only "aria-label" and "contexthelp" were invented solely for the 
benefit of people with disabilities, their exposure being limited to 
assistive technology (or JAWS and MAGIC, in the later case).

The remainder all have other uses. For example, "alt" is useful to text 
browser users, "summary" and "abbr" could in theory be used when voice 
browsers (like Opera for Windows with the Voice plugin) read data 
tables, and "axis" could be used in query engines. Some are exposed to 
typically sighted mouse users of bog standard graphical web browsers in 
everyday browsing situations ("title", "value", "prompt", "label", and 

 > , a result of those who design the language being in little touch
 > with those who must use substitutes for non-textual stuff.

Sorry, but what are you saying caused what? I read your sentence as 
saying that the fact that most of these attributes were intended to 
describe things for the benefit of people with disabilities is the 
result of language designers being out of touch with such people - but I 
doubt that's what you meant to say.

Benjamin Hawkes-Lewis

Received on Saturday, 15 August 2009 16:00:25 UTC