- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 06 Aug 2010 19:45:39 -0700
- To: HTMLwg WG <public-html@w3.org>
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
Received on Saturday, 7 August 2010 02:46:12 UTC