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

Hi Maciej,
one solution to the issue of the alt spec would be to include it in HTML5 as
a normative appendix , in this way it can be included in HTML5, but also act
as a standalone document.

regards
Stevef

On 8 August 2010 06:37, Steven Faulkner <faulkner.steve@gmail.com> wrote:

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



-- 
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 Tuesday, 24 August 2010 10:00:57 UTC