RE: Discussion on Change Proposal for ISSUE-66

Shelley Powers wrote:
>
> On Sat, Jan 23, 2010 at 5:07 PM, John Foliot <jfoliot@stanford.edu>
> wrote:
> > Can't speak for "everybody", but I agree that it is acceptable
> >
> > I think the suggestion to reference UAAG is the better way forward.
>  From
> > my perspective, Standards are by necessity "locked down", while
> techniques
> > documents and guidelines are evolutionary by design. Locking down
> "Refer
> > to UAAG" in the Standard introduces no downside, as UAAG can evolve
> to
> > accommodate newer techniques and technologies.
> >
>
> I hate to disagree with you John, but no, I'm not on the same page.

And that's cool Shelley, as I stated from the onset, I cannot and do not
speak for everybody - I speak simply for myself.

>
> Sure, there's nothing wrong with encouraging user agents to attempt to
> repair missing information,

OK, so far we are in agreement (and FWIW, this is how I interpreted
Maciej's general question - should the Standard allow this, and if yes,
should it be specifically stated, and to what degree of specificity?)

> but that doesn't eliminate the problem
> that this type of information can obscure the more important issue:
> authors need to provide this information.

No argument, but unless you are willing to drive over to their office and
fix it or force them to fix it, authors are not going to always do the
right thing. This we know, and must accept as true.  So what's Plan B? I
have previously suggested (knowing full well that I was pushing too far)
that <img> without alt should simply not render on screen, to the expected
incredulous laughter from the masses
(http://diveintomark.org/archives/2009/03/18/if-it-fails-for-some). So
what next?

> Failing authors, authoring
> tools are more likely the more appropriate technology to fill in this
> information. In fact, many authoring tools do attempt to provide this
> information if authors don't.

ATAG (Authoring Tool Accessibility Guidelines) states:
	"... producing equivalent information, such as text alternatives
for images and auditory descriptions of video, can be one of the most
challenging aspects of Web design, and authoring tool developers should
attempt to facilitate and automate the mechanics of this process. For
example, prompting authors to include equivalent alternative information
such as text equivalents, captions, and auditory descriptions at
appropriate times can greatly ease the burden for authors. **Where such
information can be mechanically determined and offered as a choice for the
author (e.g., the function of icons in an automatically-generated
navigation bar, or expansion of acronyms from a dictionary), the tool can
assist the author.** At the same time, the tool can reinforce the need for
such information and the author's role in ensuring that it is used
appropriately in each instance."
http://www.w3.org/TR/WAI-AUTOOLS/#gl-prewritten-descs
(** Emphasis mine **)


At the same time:

UAAG (User Agent Authoring Guidelines) Techniques states:
	"Allow configuration to provide access to each piece of unrendered
conditional content[1] "C".
When a specification does not explain how to provide access to this
content, do so as follows:
If C is a summary, title, alternative, description, or expansion of
another piece of content D, provide access through at least one of the
following mechanisms:
	(1a) render C in place of D;
	(2a) render C in addition to D;
	(3a) provide access to C by allowing the user to query D. In this
case, the user agent must also alert the user, on a per-element basis, to
the existence of C (so that the user knows to query D); and
	(4a) allow the user to follow a link to C from the context of D.
Otherwise, provide access to C through at least one of the following
mechanisms:
	(1b) render a placeholder for C, and allow the user to view the
original author-supplied content associated with each placeholder;
	(2b) provide access to C by query (e.g., allow the user to query
an element for its attributes). In this case, the user agent must also
alert the user, on a per-element basis, to the existence of C; and
	(3b) allow the user to follow a link in context to C."
http://www.w3.org/TR/UAAG10/guidelines.html#tech-doc-content-access

[1] Where conditional content is:
	"...Conditional content is content that, by format specification,
should be made available to users through the user interface, generally
under certain conditions (e.g., based on user preferences or operating
environment limitations). Some examples of conditional content mechanisms
include:
The alt attribute of the IMG element in HTML 4. According to section 13.2
of the HTML 4 specification ([HTML4]): "User agents must render alternate
text when they cannot support images, they cannot support a certain image
type or when they are configured not to display images."..."
http://www.w3.org/TR/UAAG10/glossary.html#def-conditional-content

As well as:

	"Allow configuration to generate repair text when the user agent
recognizes that the author has not provided conditional content required
by the format specification.

Sufficient techniques
The user agent may satisfy this checkpoint by basing the repair text on
any of the following available sources of information: URI reference (as
defined in [RFC2396], section 4), content type, or element type. Note,
however, that additional information that would enable more helpful repair
might be available but not "near" the missing conditional content. For
instance, instead of generating repair text on a simple URI reference, the
user agent might look for helpful information near a different instance of
the URI reference in the same document object, or might retrieve useful
information (e.g., a title) from the resource designated by the URI
reference."
http://www.w3.org/TR/UAAG10/guidelines.html#tech-missing-alt

So you see, the WAI have already thought about, discussed, and codified
current specifications and techniques on this particular topic.  Seems to
me, the question is closer to: "should the HTML5 Standard reference this
material?"  Here I say yes.


>
> Matt is the one who provided the change proposal, and will defer to
> him.

"I would support a statement that makes reference to UAAG requirements on
missing @alt." - Matt May
http://lists.w3.org/Archives/Public/public-html/2010Jan/1103.html

"Since there is such potential to conflate author advice with UA advice, I
would much rather put repair techniques in a section of its own. Since the
outcome of any repair techniques would vary from browser to browser, it's
a set of recommendations that may help UAs further assist users, but would
completely confound authors who might expect behavior where it may not yet
exist. If further down the line browsers can agree on a given heuristic
and commit to one technique working in a standard manner in all supporting
browsers, it can be moved back to a normative section." - Matt May
http://lists.w3.org/Archives/Public/public-html/2010Jan/1107.html

In the interest of clarity I both agree and support these statements;
especially the first one.


> But I hope that we don't get into the habit of   going outside
> the boundaries of what should be included within an HTML
> specification. Hinting to user agents that they should provide this
> information, if they can, just ensures that we'll most likely have
> inconsistent implementation--not to mention the possibility of
> providing incorrect, or even muddled information.

Shelley, user-agents are already told to do so, as the UAAG quote above
details. I think the real question is should this information *also* be
embedded into the HTML5 Standard, and I think that both Matt and I are
suggesting no.  There are appropriate places for this information, and in
particular I believe that "Techniques" document(s) is the appropriate
place, as future emergent techniques may in fact surface that we cannot
envision at this time.  Having a "locked-down" Standard that points to an
evolutionary Techniques document is, to me, a huge win for both 'camps',
as the standard does not need to be re-opened to accommodate technology
advances we cannot envision, and such future techniques have a welcoming
'home' that is directly referenced from the standard, which further
benefits authors, user-agents, and most importantly users.

>
> Then there's the issue of performance -- authoring tools only have to
> try to determine the alt text once.

...according to...? I don't see that in the ATAG anywhere, but it's
possible that I missed it. Reference URLs are always helpful.

> Do we really want every user agent
> to attempt the same process every time the web page is opened? For
> every image?

The alternative being? (And I don't have an answer here either)

I think that the fundamental question posed by this thread is, should the
HTML5 Standard:

a) Provide duplicate information along with un-proven suggestions
('heuristics') as 'repair' techniques?
b) Point to existing and evolving guidelines and techniques as the
appropriate place for further 'details'?
c) Do nothing/say nothing?

(unless I've been totally distracted the past 2 weeks, which is also very
possible)

JF

Received on Sunday, 24 January 2010 04:38:27 UTC