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

"Hi Maciej,


> I'm not familiar enough with the alt draft to understand its normativity
status.

"This specification is an extension to the HTML5 specification
[HTML5<http://dev.w3.org/html5/alt-techniques/#ref-html5>].
All normative content in the HTML5 specification, unless specifically
overridden by this specification, is intended to be the basis for this
specification.

This specification is a replacement for the sections
4.8.2.1.1<http://dev.w3.org/html5/spec/text-level-semantics.html#a-link-or-button-containing-nothing-but-the-image>
 to 4.8.2.1.11<http://dev.w3.org/html5/spec/text-level-semantics.html#an-image-in-an-e-mail-or-private-document-intended-for-a-specific-person-who-is-known-to-be-able-to-view-images>
of
the HTML5 specification and all of the normative and non normative content
of the sections there-in."

http://dev.w3.org/html5/alt-techniques/


> We can, of course, change either document based on the usual decision
process.

then my answer to your question

"can we compromise, and agree to have alt information *both* in a detailed
standalone document *and* in the HTML5 spec?"

is to allow the working group to make a decision on the change proposal (
http://www.w3.org/html/wg/wiki/ChangeProposals/ImgElement20091209)

Note: in light of your question to the group and your responses I have
updated the change proposal to include this option:

"OR

Replace the sections
4.8.2.1.1<http://dev.w3.org/html5/spec/text-level-semantics.html#a-link-or-button-containing-nothing-but-the-image>
 to 4.8.2.1.11<http://dev.w3.org/html5/spec/text-level-semantics.html#an-image-in-an-e-mail-or-private-document-intended-for-a-specific-person-who-is-known-to-be-able-to-view-images>
 under Requirements for providing text to act as an alternative for
images<http://dev.w3.org/html5/spec/text-level-semantics.html#alt>
with
the sections starting from
intoduction<http://dev.w3.org/html5/alt-techniques/#intro> and
ending after 13. CAPTCHA Images<http://dev.w3.org/html5/alt-techniques/#captcha>
 of HTML5: Techniques for providing useful text
alternatives<http://dev.w3.org/html5/alt-techniques/>
"


regards

Stevef



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

>
> On Aug 7, 2010, at 4:51 AM, Steven Faulkner wrote:
>
> 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.
>
>
> We can, of course, change either document based on the usual decision
> process.
>
>
> 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.
>
>
> Currently, the specific requirements for text equivalents in the HTML5 spec
> are normative, but not machine-checkable, and conformance checkers are not
> supposed to check for any of them. I'm not familiar enough with the alt
> draft to understand its normativity status. Certainly, anyone is free to
> file a bug suggesting change on this point.
>
> Regards,
> Maciej
>
>
>
> 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
>
>
>


-- 
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