- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Thu, 24 Apr 2008 14:49:41 +0100
- To: "Al Gilman" <Alfred.S.Gilman@ieee.org>
- Cc: "W3C WAI-XTECH" <wai-xtech@w3.org>, "Ian Hickson" <ian@hixie.ch>
I wanted To clarify one point about my previous post: It would not matter if some or all of the markup containers were empty intially, as in the case of "comments" on a photo site. The important thing is that relationships between and image and potentially related content is defined, for if and when related text is added. so for example: <img aria-describedby="commentcontainer"> <p id="commentcontainer"></p> would be conforming as the relationship is defined for when content is added. Note: please don't argue the use of aria-desribedby in this case as it is just an *example*, attribute use, some other more appropiate attribute could be used in this situation. regards steve On 24/04/2008, Steven Faulkner <faulkner.steve@gmail.com> wrote: > Hi Al, > > taking up one point in particular: > > >The text alternative will frequently be provided by @alt but WCAG provides for other markup means in principle. > > If this point is agreed, then the question can be recast: > > As an accessibility requirement should HTML5 require that some form of > related text is always explicitly associated with an image in cases > where the image does not have a "text alternative" provided. > > for example these would be conforming: > > <img aria-describedby="desc1"> > > <p id="desc1"> image caption text</p> > > or > > <h1 id="label1"> related heading text</h1> > > <img aria-labelledby="label1"> > > > or > > <figure> > <img> > <legend>image caption</legend> > </figure> > > or > <h1 id="label1"> related heading text</h1> > <figure> > <img labelledby="label1"> > </figure> > > > or a new attribute > > <img relatedtext="related"> > > <p id="related">text that is not a text alterntive but is about the image</p> > > or > > <img alt="pork scratchings" relatedtext="related"> > > <p id="related">From very humble beginnings as a regional food, Pork > Scratchings are now a national snack. Recent press publicity and > mentions in such TV soaps as Coronation Street and Eastenders have > made Pork Scratchings a household name.</p> > > > BUT instances where there are no explicitly associated text would not: > examples > > <p><img></p> > > or > > <figure> > <img> > </figure> > > or > <p><img></p> > <p>text related to the image but not associated</p> > > > This goes some way to resolving the issue of "no alt being available" > as even in systems where the alt cannot be provided or is not > provided, the design of the system can and I would suggest most always > does incoporate relationships between text that is related to the > image. As predefined markup containers for different types or related > information are commonplace. > example include: > titles > descriptions > captions > comments, > notes > really any metadata. > > If such distinctions between ,text alternative, description, label etc > are provided within the markup language (as they are or could be) it > would be easy enough for the AT to provide options to the user on how > they want the content announced in relation to an image. > > This means that the important requirement that *some* textual content > that is relevant to an image is programmatically associated with the > image, even when the most desirable, a "text alternative" value > provided using alt attribute is unavailable. > > regards > stevef > > On 22/04/2008, Al Gilman <Alfred.S.Gilman@ieee.org> wrote: > > > > Reference: discussions of if and when the HTML5 specification should > > tell authors to omit the @alt attribute, in the TR page draft at > > http://www.w3.org/TR/html5/#the-img > > .. and on this list. > > > > Caveat 1: these are personal perceptions, not PFWG consensus > > > > Caveat 2: I'm not going to try to give direct answers to the questions > > that have been asked of PFWG. I want to get some ideas out here that > > address > > > > (1) the 'feasible range' of a solution that all can live with > > > > (2) the considerations that should be weighed in selecting a solution > > within that feasible region. > > > > ** Summary: > > > > * Cautions to editor: > > > > 1. The two examples offered for when a missing @alt might be the highest > > and best markup available to the encoding sofware are ill-chosen. > > They don't pass accessibility review as exemplifying the logical > > conditions they are supposed to represent. > > > > 2. Don't say that this markup advice is for *important* images where > > you don't know what to provide as a text alternate. The 'important' > > restriction is not appropriate. The same markup approach should apply for > > unimportant images where you don't know that they are unimportant. And make > > it clear that the "human didn't bother" case is included. It probably > > represents the lion's share of the missing @alt attributes out in the wild > > today; > > so if we are going to try to address this as a common case, > > unknown-to-be-decorative images should be included and not just other > > unknown-what-to-say images thought to be 'important.' > > > > * Cautions to the 'required is required' advocates: > > > > 3. The HTML5 draft is attempting to provide markup for what has > > in practice been a common case: insufficient human thought has > > been applied to the web-posting of an image for there to be a > > known-good @alt value for that image. That is to say, known > > to the software module that is performing the markup encoding of > > the content on its way to the web. While there are downsides > > to eliminating the simple statement "@alt is required," there are > > upsides to the fact that the information provided to client-side > > repair activity is of greater accuracy. > > > > 4. WAI has at least in some cases set a precedent for a prominent > > informative reference to the WAI Recommendations as an acceptable > > alternate to a copy-in of WAI Guideline provisions or a normative > > reference to them. > > > > for example SpecGL: > > http://www.w3.org/TR/qaframe-spec/#address-other-topics > > > > 5. The real pain if HTML5 is more subtle about "text alternate" > > requirements than just saying "@alt is required; Do It," comes > > in accessibility education. But don't underestimate the power of > > running code. If the author's tools flag @alt problems more > > consistently; that replaces many many hours of lecture time in > > the classroom, in terms of "good text alternates" that wind up > > in the live Web. It matters less what reference appears in the > > footnote at the end of the discrepancy-explanation. More that > > the author gets alerted to the discrepancy more consistently. > > HTML WG and HTML5 specification can help us > > get there; do consider reasonable alternatives. > > > > ** longer, stream-of-unconsciousness mutterings > > > > +1 to "web pages where the page doesn't know what to say as the @alt > > value are common." > > > > Note 1: The language in the 22 January 2008 draft poisons the debate by > > talking > > only about "important" images where a suitable @alt value is not known. > > That is misleading. Most of the time, if you know the image is important, > > you have something better to say that "I don't know" by way of an @alt > > value. If you don't know what to say in @alt, you don't know if it is > > 'important' or not. If the specification is going to state conditions > > under which the @alt attribute is to be omitted, they should be "I don't > > know" conditions spanning both important and decorative (but unknown > > decorative) > > images as well. > > > > in: http://www.w3.org/TR/html5/#the-img > > ..where it says "A key part of the content that doesn't have an obvious > > textual alternative" > > > > Note 2: In particular, most accessibility experts will not agree that > > the photo upload use case is one where the authoring tool could not > > come up with something that is better than nothing. So the example > > adds more heat than light. > > > > Something on the order of > > > > $userScreenName's Nth photo [ uploaded | taken ] $date [ $time ] > > > > is something that uses information the generator of the HTML access > > page for the uploaded image files has available and is arguably better > > than nothing. > > > > -1 to "bad @alt is worse than no @alt in many situations" > > > > .. could not confirm this with the user community. > > > > +1 to "required @alt is persuasive in training sessions" > > > > Accessibility staff get limited time to educate developers. They > > don't have time for subtleties. A clear DoIt tends to get action. > > > > .. interpretation: If @alt is not required, there is damage to the > > accessibility outreach effort; some mitigating measures to offset > > this should be considered. > > > > Possible mitigating measures include things like: > > > > (a) where the specification says that the missing @alt is undesirable, > > it instead say is contrary to the applicable W3C Recommendation and > > cites WCAG. > > > > (b) in its processor provisions, HTML5 says that authoring tools > > should provide a conformance checking function, and that in the shipping > > default configuration of that conformance checking function, a missing text > > alternative (Note 3) will be flagged as a defect, with a help trail that > > leads > > back to the WCAG standards. > > > > Note 3: the test should be that the "text alternative" > > http://www.w3.org/TR/WCAG20/#text-altdef > > as described in WCAG2 is not defined by the markup. It is within the > > purview of the HTML5 specification to provide that the legend of a figure > > structure is in the search list to be the text alternate for the image > > in that structure, for example. The text alternative will frequently > > be provided by @alt but WCAG provides for other markup means in principle. > > > > On the other hand... > > +1 to "Missing @alt cues repair, and this is useful." > > > > Present client-side processing is centered around the following pattern: > > if @alt="" the image is ignored. if @alt is not there, processors may > > and sometime do attempt some sort of repair. The filename of the image > > is commonly used as a substitute. > > > > Note 4: In the case of the Specification Guidelines (SpecGL) the WAI agreed > > that > > the SpecGL document should not re-ordain what was already ordained in the > > WAI Guidelines, but rather should include an informative but conspicuous > > reference to the WAI Guidelines at critical points of relevance. > > > > http://www.w3.org/TR/qaframe-spec/#address-other-topics > > > > This is a precedent for having the HTML5 specification cite the WCAG > > requirement for a text alternative; rather than substituting a different > > requirement, or making a normative re-statement that creates two documents > > purporting to be the origin of the same requirement. > > > > Note 4: The Rorschach test example is also not a valid example of what > > it attempts to illustrate. It is clear from the following WCAG language > > > > <quote > > cite="http://www.w3.org/TR/2007/WD-WCAG20-20071211/#text-equiv-all"> > > (3) a test or exercise that must be presented in non-text format, (4) > > primarily intended to create a specific sensory experience, then text > > alternatives at least provide descriptive identification of the non-text > > content > > </quote> > > > > .. that there are appropriate things to say in a text alternate in this > > case, and why not use @alt to say them? > > > > In other words, "ink blot" or "test stimulus" would, either of them, be > > appropriate @alt values and in 'no way' is there is no way to provide > > an appropriate text alternative. > > > > Al > > > > > > > -- > 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 Thursday, 24 April 2008 13:50:20 UTC