Re: using an attribute to categorize the @alt state [was Baby Steps or Backwards Steps?]

I think a question needs to be asked:
Will the change in the html 5 spec (optional @alt) from the html 4 spec
(required @alt) result in more images used under any circumstance having no
alt attribute specified?

It could be said that obliging authors to provide alt text has resulted in
many meaningless alt texts being provided, but it may also be true that the
obligation has resulted in a greater acknowledgement and uptake of alt text
provision because it has been authors brought to the authors attention
through its requirement.

I believe that having alt required, has put the onus on the author to
provide an appropriate alternative text and the authoring tool vendors to
prompt authors to provide it. Giving authors/tool vendors an opt out clause
(it's required unless) could lead to a creeping "de-altification" of img
elements.

there has been some talk on irc about defining the circumstances under which
no alt attribute is legitimate:
[http://krijnhoetmer.nl/irc-logs/whatwg/20070817]

<Lachy> Hixie, would it be possible for the spec to provide some sort of
heuristic guidelines for programmatically determining when should be
provided? e.g. if you have <h1><img src=""></h1>, it should be clear for a
validator that the lack of alt text is an error.
# <http://krijnhoetmer.nl/irc-logs/whatwg/20070817#l-284> [09:03]
<othermaciej> you could require alt in any context that would require text
if the embedded content wasn't there
# <http://krijnhoetmer.nl/irc-logs/whatwg/20070817#l-285> [09:03] <Lachy>
could it be defined that alt="" can only ever be omitted when contained
within a <figure>, since that would represent it as a key part of the
content
# <http://krijnhoetmer.nl/irc-logs/whatwg/20070817#l-286> [09:03]
<othermaciej> or something
# <http://krijnhoetmer.nl/irc-logs/whatwg/20070817#l-287> [09:04] <Lachy>
currently, all the examples in that section where alt can be omitted are
contained within figure too
# <http://krijnhoetmer.nl/irc-logs/whatwg/20070817#l-289> [09:06]
<othermaciej> allowing missing alt only in <figure> would address the photo
gallery use case but not the "pasting images into an end-user rich text
editor" use case

Why not use the same logic to define what alt="" means in a particular
circumnstance:

 Could it be not defined that alt="" when contained within a <figure>
represents it as a key part of the content??



On 17/08/07, Robert Burns <rob@robburns.com> wrote:

>
> HI Smylers,
>
> On Aug 17, 2007, at 3:30 AM, Smylers wrote:
>
> >
> > Jon Barnett writes:
> >
> >> On 8/16/07, Robert Burns <rob@robburns.com> wrote:
> >>
> >>> I can't think of a good name for this attribute, but consider
> >>> something like @embedrel (required) for now (name suggestions
> >>> welcome). The value of this attribute would reflect the scenarios
> >>> identified in the recent changes to the draft. missing, icon,
> >>> decorative, seecontext, seefallback. The value 'missing' would be
> >>> the default value, unless '@a't had a string (or perhaps some other
> >>> contingencies for content backwards compatibility )  so not setting
> >>> either @alt or @embedrel would be considered 'missing'.
> >>
> >> I am by no means opposed to a new attribute for indicating that an
> >> image intentionally has no @alt text, i.e. a new attribute to do what
> >> omitting @alt does now.  The suggestion was @noalt, Maciej has
> >> mentioned it in a recent message.  If it can be proven that either
> >> (a)
> >> enough UAs treat missing @alt the same as alt="" or (b) enough
> >> authors
> >> omit alt when they really mean alt="", then I'd be in favor of that
> >> attribute.
> >
> > We'd also need to define what user-agents should do if:
> >
> > * an img has both noalt and alt=""
> > * an img has both noalt and a non-empty alt
> >
> > By using two separate attributes we introduce the scope for
> > self-contradictory documents.  An advantage of using 'not having an
> > alt
> > attribute' to mean 'noalt' is that it's impossible to simultaneously
> > both omit the alt attribute and include it.
>
> The proposal is not for a noalt boolean attribute. Its for a keyword
> value attribute that deals with many of the issues raised.
>
> I actually did specify how UAs should interpret that in this message:
>
> <http://lists.w3.org/Archives/Public/public-html/2007Aug/0647.html>
>
> I think I may have gotten some of that wrong. There I said:
>
> quote
> @alt (required in some contexts)
> @embedrel (required) with keywords:
>    • missing (whether @alt is there or not its value has no meaning)
>    • decorative (whether @alt is there or not its value has no meaning)
>    • icon (whether @alt is there or not its value has no meaning)
>    • seecontext (whether @alt is there or not its value has no meaning)
>    * seefallback (@alt is required or for other elements the elements
> contents must contain non-<source> and non-<parameter> content
> providing a textual equivalent for the embedded resource.
> unquote
>
> But I think I may have gotten the icon scenario wrong there. It
> should probably be
>
>    • icon (@alt is optional; if specified it provides the alternate
> text for this resource)
>
> There may be other tweaks that would help.
>
> I understand your concern about these being out of sync. However,
> looking down the list, I think its not that big of a concern. Most of
> that concern is tied up with simply a mis-specified value for
> @embedrel. And that's a concern for any attribute.
>
> I think the other benefit to this approach is that even if @alt is
> specified and the @embedrel keyword is mis-specified, AT and other
> UAsj could provide users with the option to delve deeper to see if
> there's any @alts where there shouldn't be. Much of my motivation
> here is trying to cover the use-case where a user is trying to
> comprehend a page, but something seems to be missing. If an entire
> page appeared to have incorrect @embedrel values a user could even
> turn off UA processing of that attribute for the entire page or the
> entire site. The approach provides a lot of flexibility I think.
>
> Take care,
> Rob
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html