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: Mon, 9 Aug 2010 15:34:52 +0100
Message-ID: <AANLkTinxVAyQgkexj39chpKRqKeAywhzaJm=3KPMWEVr@mail.gmail.com>
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: Maciej Stachowiak <mjs@apple.com>, HTMLwg WG <public-html@w3.org>
Hi Laura,

I would consider any resolution to the issue that improves the chances of
accessible content being produced.


regards
stevef
On 9 August 2010 12:57, Laura Carlson <laura.lee.carlson@gmail.com> wrote:

> Hi Steve,
>
> Maciej wrote:
>
> > "can we compromise, and agree to have alt information *both* in a
> > detailed standalone document *and* in the HTML5 spec?"
>
> To have text alternative information in both documents and ensure that
> both...
>
> * Are in harmony and do not contradict each other.
> * Do not get out of sync.
> * Are better in line with W3C accessibility guidelines, developed over
> many years.
>
> Here is an idea...
>
> Use a server side include to include the contents of "HTML5:
> Techniques for providing useful text alternatives" [1] replacing,
> correcting, and improving 4.8.2.1.1 to 4.8.2.1.11 in the HTML spec
> [2].
>
> This would also reduce maintenance in the HTML spec.
>
> Steve would you be agreeable to using a SSI?
>
> Best Regards,
> Laura
>
> [1] http://dev.w3.org/html5/alt-techniques/
> [2] http://www.w3.org/TR/html5/embedded-content-1.html#the-img-element
>
>
> >> 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
> >>
> >>
> >>
> >
> >
> > --
> > 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
>
> --
> Laura L. Carlson
>



-- 
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 Monday, 9 August 2010 14:35:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 August 2010 14:35:47 GMT