what's machinable [was: Re: ALT issue redux]

** summary:

You hit the nail on the head when suggested that @alt is not the
only markup pattern we need.  For HTML5 we need to look at how
a variety of markup patterns can meet the functional requirement
set out in WCAG2 that there be a textual alternate.

The ARIA @labelledby attribute is one candidate.

But there are also possibilities to identify the text alternate
by algorithm.  The SSML <audio> element has semantics that
clearly make the text content of the element an alternative
to the media object cited in the @src attribute.  This pattern
is replicated throughout XHTML2.

Not to say that HTML5 is going to take up all features of
XHTML2, just to say that there are multiple ways to skin
a cat, and some of the plausible approaches are algorithmic.
Compare with the @headers evolution discussion.

The point that I was trying to make in talking about machinable
stuff is that where a textual alternate is required, the
association of the text and its non-text alternate needs to
be clear in the markup semantics.

The present draft falls short in the area of articulating
what the algorithm is that links text and non-text
in the cases where (a) a textual alternative is required and
(b) they and we could agree that an empty @alt is OK, because
of another text-content fragment that does the job.

We need to know what the "alternate alternate" is when @alt
is not doing the job.

** long form interleaved

On 1 Feb 2008, at 5:44 AM, Joshue O Connor wrote:

>
> Al Gilman wrote:
>> We need effective
>> action across the board.
>
> As a suggestion, one way to do this may be to not mix issues even if
> they may be related (where possible).

Well, how separately one can treat related issues is an art that
neither W3C nor WAI have mastered to any high degree, ..

One of my FAQs is that "The people with the answers see the world
through a more fine-grained reticle (system of sorting categories)
than do the people with the questions."

So ultimately we need to see how the questions get answered
both in the large and in the small.

> Re:
> Conformance/error-checking/accessibility.
>
>> There are several other cases where the instructions in the HTML5  
>> draft
>> are that the @alt should be empty.  These are similar to putting a  
>> null
>> @alt on an image in an image link when the link @title is desired  
>> to be
>> spoken.
>
> In the wild @title content is rarely outputted by screen readers.

I must have the example wrong.  I was trying to say that there is an
existence proof where the accessibility techniques recommend @alt=""
beyond the case of spacers and the like.  Could it be in link content
where the text content already in the link is right, without anything
added for the icon?

>
>> I think that these cases need to be identified by machine-applicable
>> selectors before the "no @alt" instruction can be acceptable.
>
> <Thinking out loud> Is there a need to successfully deal with @ALT
> content for human users and then @ALT that is machine readable. Is  
> this
> correct? If so, can the same attribute satisfy both these  
> requirements?
> Or is there a need for @ALT x 2 or @ALT plus machine selector? How  
> would
> this be generated, via some option in the authoring tool? Would the
> machine readable selector satisfy the requirements for situations  
> where
> there is no@ALT ?

You are right there are different requirements in the different use
cases.  And my current thinking is that @alt doesn't meet all the  
requirements
and would be awkward to try to stretch that attribute to meet them all.

For example in HTML+ARIA we have @labelledby that lets us point by ID
to something that can contain markup.  Better for i18n, better
in general than @alt that only can contain a text string, no markup.

In the case of the link text, there is a fairly simple rule:  The
text content of the <a> element is well defined by the syntax.  If this
is the explanation you need the link content to provide for access, then
it's OK if an icon marking the link hides from the text view, and  
doesn't
add anything.  This is a pattern that an accessibility checker or author
prompting algorithm can readily apply.

Note that this doesn't have to be the final answer for HTML5.  WCAG2
allows link identification from the link element content to be  
"unique, given the context."
Defining an algorithm for what text in the context of a link should be
considered part of the orientation to the link destination -- if HTML5
wants to take that approach, we need to consider it.

What I want is those case-diagnostic patterns spelled out, not just
heuristic prose.  Where the @alt is to be left empty by rule because
there is peer content that is the text alternative, how does the AT
find the text alternative that is there?  There should be a way.
That's what should be machinable.

>> In other cases, where an image amplifies some text also in the page,
>> the relationship of the image to the text must be machine  
>> recognizable.
>> People with reading difficulties need the association to be machine-
>> recognizable because they may be critically dependent on the image to
>> grok the words.
>
> When you say "amplify" do you mean that the image is complementary  
> or is
> used as an to aid comprehension? If so, then yes.

> If not then I would argue that in many cases the relationship  
> really does not need to be
> explicit for human consumption.

What is "explicit for human consumption" is a presentation decision
subject to "author proposes, user disposes."  It is not available to
the format from the author as settled fact.

The point is that if the association is *useful* as an aid there are
*some people* for whom the association is critical.  Giving the author
some slack, we will assume that meeting those people's needs may require
some AT on the client side.  But the association should be *explicit
at the format (=machine) level so that it can be made overt to those
users who *need* it as opposed to the rest of the users for whom it
is a "nice to have."

> The way images are used is often quite
> arbitrary, even if they are used to aid comprehension and while an  
> image
> can speak a thousand words and so on, a few well chosen words often  
> will
> suffice.

People think they stuff media objects in for no reason. It's just that
it's harder to articulate the reason than it is to decide to do it.

[historical flame on this point:
http://lists.w3.org/Archives/Public/wai-tech-comments/2001Aug/ 
0001.html ]


> FWIW I would also suggest that the semantic relationship between an
> image that "amplifies" text is different from what @ALT does.

Yes, @alt doesn't meet all requirements.  Nor should we try to make it.

> Maybe
> there is a need for an attribute that more explicitly states that
> semantic difference? Rather like @ADD (for additional, or addendum) or
> @SUPP ( for supplementary),  etc.

So far in WAI-ARIA we are sticking with @labelledby and @describedby
which are roughly parallel to @alt and @longdesc but more broadly
applicable.

Getting into subtler distinctions by trying to apply SKOS to show the
gradations in meaning-relationship turned into a non-terminating  
process.

>
>> Given the low level of strict conformance to W3C format  
>> specifications
>> in the Web as she is spoke today, it is not clear how much of a prize
>> it is to insist that a missing @alt in this case is a format error
>> vs. just being an accessibility error (which it will be anyway).
>
> There seems to be two issues here.

.. and they are?

The goal is a Web populated with content PWD can use.  At that level
there is one issue.

In terms of who does what where to make this happen, there are more
than two options.

Here there is only one issue.  The HTML5 draft agrees already that
critical content *should* have a text alternative.

The problem is that the language in the draft is so vague.

The alarmist interpretation would be that they want to overrule WCAG.
I don't think so.

It could also be taken to mean "although this is wrong, this is a
defect that browsers will have to tolerate."

>> We should regard the HTML WG desire to standardize recovery from  
>> defects
>> as a positive step.  Something that we should applaud and work with.
>>
>> Clearly, the absense of an @alt in the narrow case described above
>> should not be cause for the browser to reject the whole document, as
>> is the uncomfortable rule with many XML errors.
>
> Absolutely.

Thanks.

aside: I have an un-finished guideline about "me too" messages.  I
think it helps to have a second voice on record in agreement.  Too
many can get just contribute to inbox glut.  But it's hard to
articulate a netiquette principle that will get followed in the
wild.

Al

> Cheers
>
> Josh
>
>
>
>

Received on Monday, 4 February 2008 18:19:21 UTC