Reading through the current spec:
The flowhart example in 4.8.2.1.2 [1] seems to me to be good alt text. It
does violate the principle of visible metadata (if you change your
flowchart you don't see the metadata that it illustrates, and the
associated accessibility use case of people who have some functional
vision, but not a lot.
As described on this list somewhere in the past, such people typically
look at the pictures, and read the text - sometimes the images help,
sometimes they don't and the text description is necessary. Putting it in
the alt, rather than somewhere in the page, or putting it in the page
without a clear way to know that it refers to a given image, both increse
the required work to be sure that the user has understood what is there
(understanding alone is insufficient. A user needs to be clear that they
have in fact understoof all of what is there - a subtle distinction which
only sometimes has practical application, but which is important when it
does).
A better approach, IMHO, would be to have the image illustrating the text,
such as:
<p>In the common case, the data handled by the tokenization stage
comes from the network, but it can also come from script.</p>
<p><figure><img src="images/parsing-model-overview.png"
alt=""><legend>Figure 41</legend><p>
<p>As shown in figure 41, the network
passes data to the Tokenizer stage, which passes data to the Tree
Construction stage. From there, data goes to both the DOM and to
Script Execution. Script Execution is linked to the DOM, and, using
document.write(), passes data to the Tokenizer.</p>
You may not want to do this, or for reasons of flow to have the detailed
data elsewhere. This is where longdesc/describedBy can be helpful.
The issue that arises is copy/paste coding - if you do that in a text
editor as opposed to an authoring tool (because the latter are already
sometimes smart enough to carry the associated code, and we could clarify
which ones are helpful and which ones help authors break things) then a
relative description link to an internal reference needs to be made (more)
absolute. On the other hand, if I use wiki commons images, or things that
Ian has described somewhere on the WHATWG site, and the references point
to these external pages, I simply copy/paste and have automatically
inherited a good description too.
Such an example may look like
<p>In the common case, the data handled by the tokenization stage
comes from the network, but it can also come from script.</p>
<p><img src="images/parsing-model-overview.png" alt="document.write() can
provide input too."
longdesc="http://whatwg.org/images/descriptions/parsing-model-overview.html";></p>
longdesc is effectively the same as aria-describedBy, although
historically limited to a very few elements - it is here for better
backwards compatibility, not because I care much either way about the name.
In any event, what happens to an AT user (whether a screenreader or
someone running a simple script extension such as [2] or [3]) is that you
see the image, and you can get a further description if you want. (In this
example it is an edge case, but this is still a relatively simple diagram.
For something more complex this becomes more relevant.
Such an example might be the common "problem-solving" flowchart [4] I have
seen this in most developer contexts I have been in - it is the one that
starts "Is it working? If so, leave it alone. If not, did *you* mess with
it? if you didn't, will things be OK if you leave it alone, or are you
unfortunate enough that you will get the blame? And if you did, you are a
fool, but the question is whether anyone will find out..." (That's
probably more description than necessary here. If someone had described
the thing accurately once, and such descriptions were more readily
available, I would simply look for the description and point to it :) )
Everything then looks OK until the third example of 4.2.8.1.5 [4] where
the figure element is considered seperate to the paragraph it follows, and
it is therefore suggested that text is required. This leads to a horrible
repetition. Again, having a way to clearly associate the paragraph with
the image would be helpful, but in any case the repetition of text because
it matches some theoretical pattern should be removed, since in real use
it will simply annoy users who rely on reading the alt text. (The
preceeding sections and the general advice that follows rightly point out
that repetitively redundant multiple versions of the same thing are not
helpful...)
The final example in that section is good, but it is impossible to know
that there is in fact a clear description of the image - you have to guess
it by context. It would be nice to have something like
<p id="results">According to a study covering several billion pages,
about 62% of documents on the Web in 2007 triggered the Quirks
rendering mode of Web browsers, about 30% triggered the Almost
Standards mode, and about 9% triggered the Standards mode.</p>
<p><img src="rendering-mode-pie-chart.png" alt=""
aria-describedBy="#results"></p>
Which would enable copying authors to point to the description in the
original context, or to note that it existed and copy it - this can be
done automagically by authoring tools (some do and some don't right now,
but it isn't rocket science to maintain links when you move them from page
to page).
The example in 4.2.8.1.9 [5] where the image is a key part of the content
shows how the current model is limited and why I raised ISSUE-30. A
non-text user trying to skim through a set of images (the scenario
described) quite possibly doesn't want to hear the complex descriptions of
each photo in turn.
If you can determine the user's intent in looking through the list of
images, you can decide dynamically whether the caption is enough. This
would apply where the user is just trying to find out what is in the list,
or is looking to see if their OS is there and don't understand the
find-in-page function, at least. If the user is actually trying to
determine what each OS listed looks like, then you do need the big blocks
of text available. Unfortunately, software that determines user intent is
in its infancy (and often cursed by people for its inaccuracy), and a
better solution for the next few years seems to be a method of encoding
content that readily supports several use cases at once.
Having the ability to use a linked description (and that being clarified
in this section of the spec as a good thing for certain use cases) would
make a number of the examples in this section nicer. Being able to reuse a
high-quality description of known images, instead of being asked to
squeeze something into alt text, shows authors a path where for less work
they can often achieve better results. Even in something as complex as the
Rorschach inkblots, looking for a reference or two is easier than figuring
out how to describe it (it took me five minutes to find something worth
referring to for all ten images, and I would have been hard-pressed to
describe a single one in that time).
Given that the WAI folks are finialising input on what to do in the case
where there is no known input I will refrain from comment for now.
I wrote ages ago:
Section 4.8.2.1.11 "An image in an e-mail or document intended for a
specific person who is known to be able to view images" seems to me
mildly harmful.
Specifically, it appears to legitimate claims of the kind "all our
customers can see, so we don't need to worry", something that causes
a huge umber of problems in ensuring accessibility where it is in
fact necessary.
and Ian replied
I've changed that section to make it clear it is only referring to
private documents and not anything on the Web.
That section [6] is not entirely clear on first reading (the double
negative isn't helpful). More to the point this is a more-or-less
untestable statement of intent, and I am not sure why any tool would
bother having a setting for "I am writing to somebody I know, and I don't
intend to publish this later on the web, no for either of us to use a text
editor" but would not have a setting for "I don't care about validation,
right now I want to do this". (I don't know of any validation service that
makes such an exception possible, and I don't see the use case for
building one - I certainly haven't seen it described anywhere).
It also seems to me that guidance for markup generators [7] (section
4.8.2.1.13) should also take a lead from ATAG[8] which is produced by a
group that has worked on that topic for a decade or so, and who have
maintained a consistent approach that markup generators "must not add alt
attributes with dummy values". A reference to either the ATAG 1
recommendation on that [8a], or the equivalent section of ATAG 2 [9] would
probably be in order along with aligning closely with what is said in that
spec (or convincing them to change it in future ATAG 2 drafts if they are
wrong, which amounts to the same thing).
[1]
http://dev.w3.org/html5/spec/Overview.html#a-phrase-or-paragraph-with-an-alternative-graphical-representation:-charts-diagrams-graphs-maps-illustrations
[2] http://userjs.org/scripts/browser/enhancements/frameset-links
[3] http://www.splintered.co.uk/experiments/55/
[4]
http://dev.w3.org/html5/spec/Overview.html#a-graphical-representation-of-some-of-the-surrounding-text
[5] http://dev.w3.org/html5/spec/Overview.html#a-key-part-of-the-content
[6]
http://dev.w3.org/html5/spec/Overview.html#an-image-in-an-e-mail-or-private-document-intended-for-a-specific-person-who-is-known-to-be-able-to-view-images
[7]
http://dev.w3.org/html5/spec/Overview.html#guidance-for-markup-generators
[8] http://www.w3.org/TR/ATAG10
[8a] http://www.w3.org/TR/ATAG10/#check-no-default-alt
[9] http://www.w3.org/TR/2008/WD-ATAG20-20080310/#gl-manage-alts
cheers
Chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
