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