W3C home > Mailing lists > Public > public-html@w3.org > August 2010

Re: Specific points of controversy relating to alt text (ISSUE-31, ISSUE-80)

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Sat, 7 Aug 2010 12:51:29 +0100
Message-ID: <AANLkTim8M=aLHF_0RWE5QtYDERULRPUMvV0xPeUqf4D7@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: HTMLwg WG <public-html@w3.org>
Hi Maciej,

>Query for the Working Group: can we compromise, and agree to have alt
information *both* in a detailed standalone document >*and* in the HTML5
spec? None of the arguments presented seem to require the information to be
exclusively in one form or the >other.

I could agree with this IF the information in the spec in regards to non
machine testable requirements was NOT normative AND the content was sourced
from the standalone document AND did not contradict advice provided in the
standalone document. Also the standalone spec is clearly referenced from the
alt section in the spec.

If the non machine testable requirements in the HTML5 spec were informative
ONLY, it may also make sense for them to be informative only, in the
standalone spec.


regards
stevef


On 7 August 2010 03:45, Maciej Stachowiak <mjs@apple.com> wrote:

> Hello HTML Working Group,
>
> Studying the Change Proposals for issues 31 and 80, it seems to me we can
> break down this issue into a number of sub-issues. It also seems to me that
> we may be able to achieve consensus on at least some of the specific
> sub-points, based on recent discussion. I'd like to especially commend Jonas
> and Laura for engaging in constructive discussion over the past week or two,
> as well as everyone else who contributed to the conversation.
>
> I believe we may be able to achieve consensus on some specific sub-issues,
> leaving us with a smaller subset that may need to be resolved via survey.
> For each sub-issue I have noted my observation. I'd like to hear from the
> Working Group on these points.
>
> 1) Should specific alt requirements for authors be in the HTML5 spec or in
> a separate draft?
>
> - Good arguments were presented for having a standalone document giving a
> rich, detailed treatment of text equivalents. An initial version has been
> published as a First Public Working Draft by the Working Group. It was
> argued that this could raise visibility.
> - Good arguments were also presented for having information about specific
> cases for alt in the HTML5 draft itself. It was argued that this would help
> with awareness for authors who may not have thought about accessibility up
> front.
>
> ** Query for the Working Group: can we compromise, and agree to have alt
> information *both* in a detailed standalone document *and* in the HTML5
> spec? None of the arguments presented seem to require the information to be
> exclusively in one form or the other.
>
>
> 2) Should we keep the email / private communications exemption to the alt
> requirement?
>
> - Some have said this waters down the alt requirement too much.
> - Some have argued that, in the situations where this seems more helpful,
> the generator exception would apply anyway, and the remaining cases are too
> narrow to be worth a special validator setting.
> - It has been pointed out that the intended recipients of a document are a
> subjective factor, one that cannot be determined from looking at the
> document alone, and one that may change over time.
> - It has been argued that a manual validator switch is a confusing way to
> serve a particular authoring use case.
>
> ** Query for the Working Group: can we agree to remove this exemption, as
> largely superseded by the generator exemption?
>
>
> 3) Should we keep, remove or modify the generator exemption to the alt
> requirement?
>
> - Some have argued that this exemption should be removed entirely, since it
> removes the alt requirement too much.
> - Others argue that, without this exemption, content generators will be
> forced to choose between producing nonconforming documents, or adding bogus
> alt text.
> - Still others suggest that a per-element mechanism may be more acceptable
> than a global setting to enable the generator exemption (e.g. @missing or
> @noalt attribute).
>
> I would like to add a thought of my own: there is a technical benefit to a
> per-element mechanism rather than a global one. Imagine the case of a
> template that includes some content images, but also has slots that may
> contain unknown, user-generated images. Perhaps it is a "stationery"
> template for email, or a blog theme. It would be very useful to validate the
> original template contents fully applying an alt requirement, but to apply
> the generator exemption only to the unknown user-provided content that is
> inserted as a template. This is better served with a per-element mechanism
> instead of a per-document mechanism.
>
> ** Query for the Working Group: can we compromise on a per-element
> generator exemption mechanism, rather than outright removal or retention of
> the current per-document mechanism?
>
>
> 4) Should we remove the figure/figcaption exemption to the alt requirement?
>
> - One Change Proposal effectively suggests this removal, by proposing that
> there be *no* exemptions.
> - However, there does not seem to be a great deal of enthusiasm for
> removing this exemption, and even the advocates of this removal have mixed
> feelings.
>
> ** Query for the Working Group: can we set aside the call to remove the
> figcaption exemption, particularly given a favorable outcome on (2) and (3)?
>
> 5) Should we add aria-labeledby to the list of alt exemptions?
>
> - Some in the accessibility community favor this exemption, to enable use
> of ARIA without alt.
> - Others argue that this would be a layering violation.
> - An argument was also made that this would interfere with user agents such
> as text-only browsers that cannot display images, but are not assistive
> technologies as such.
> - There is also a general desire to minimize the number of exceptions to
> the alt requirement, to avoid watering it down. This would seem to argue
> against adding more exemptions.
> - It seems that, for many who advocate cleaning up alt, this particular
> change is a relatively minor part of their concerns, and not one of the key
> issues with the current spec.
>
> ** Query for the Working Group: can we set aside the call to add
> aria-labeledby to the list of exemptions, particularly given a favorable
> outcome on (2) and (3)?
>
>
> 6) Should we add role=presentation to the list of alt exemptions?
>
> - The arguments pro and con are much as for point (5).
>
> ** Query for the Working Group: can we set aside the call to add
> role=presentation to the list of exemptions, particularly given a favorable
> outcome on (2) and (3)?
>
>
> 7) Should we remove the title attribute exemption to the alt requirement?
>
> - There hasn't been a lot of discussion on this point.
> - Input from the WG is welcome. Is this one of the biggest points of
> concern?
>
> This is a point that we may not be able to resolve by consensus, even if we
> resolve the others.
>
>
> 8) Should the semantic definition of the img element be changed, from
> saying it represents "an image", to saying that it represents "content that
> can be rendered visually (as an image) and textually"?
>
> - There hasn't been a lot of discussion on this point.
> - Input from the WG is welcome. Is this one of the biggest points of
> concern?
> - This particular point, taken alone, doesn't seem to have material impact
> on what UAs or conformance checkers will do.
>
> Perhaps we can drop this mostly-editorial change, if we can get closer to
> consensus on the more technical points above.
>
>
> If any of these sub-issues leads to extended discussion, please consider
> forking a separate thread with a new subject line.
>
>
> Regards,
> Maciej
>
>
>
>
>


-- 
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
Received on Saturday, 7 August 2010 11:52:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 7 August 2010 11:52:23 GMT