- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Tue, 24 Aug 2010 11:00:04 +0100
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: HTMLwg WG <public-html@w3.org>
- Message-ID: <AANLkTik5H4qmGeAf9TmuJnazV5c7uQzCJ-P=FoemSS-9@mail.gmail.com>
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