- From: John Foliot <jfoliot@stanford.edu>
- Date: Sat, 23 Jan 2010 20:37:42 -0800 (PST)
- To: "'Shelley Powers'" <shelley.just@gmail.com>
- Cc: "'Maciej Stachowiak'" <mjs@apple.com>, "'Matt May'" <mattmay@adobe.com>, "'HTML WG'" <public-html@w3.org>, <public-html-a11y@w3.org>
Shelley Powers wrote: > > On Sat, Jan 23, 2010 at 5:07 PM, John Foliot <jfoliot@stanford.edu> > wrote: > > Can't speak for "everybody", but I agree that it is acceptable > > > > I think the suggestion to reference UAAG is the better way forward. > From > > my perspective, Standards are by necessity "locked down", while > techniques > > documents and guidelines are evolutionary by design. Locking down > "Refer > > to UAAG" in the Standard introduces no downside, as UAAG can evolve > to > > accommodate newer techniques and technologies. > > > > I hate to disagree with you John, but no, I'm not on the same page. And that's cool Shelley, as I stated from the onset, I cannot and do not speak for everybody - I speak simply for myself. > > Sure, there's nothing wrong with encouraging user agents to attempt to > repair missing information, OK, so far we are in agreement (and FWIW, this is how I interpreted Maciej's general question - should the Standard allow this, and if yes, should it be specifically stated, and to what degree of specificity?) > but that doesn't eliminate the problem > that this type of information can obscure the more important issue: > authors need to provide this information. No argument, but unless you are willing to drive over to their office and fix it or force them to fix it, authors are not going to always do the right thing. This we know, and must accept as true. So what's Plan B? I have previously suggested (knowing full well that I was pushing too far) that <img> without alt should simply not render on screen, to the expected incredulous laughter from the masses (http://diveintomark.org/archives/2009/03/18/if-it-fails-for-some). So what next? > Failing authors, authoring > tools are more likely the more appropriate technology to fill in this > information. In fact, many authoring tools do attempt to provide this > information if authors don't. ATAG (Authoring Tool Accessibility Guidelines) states: "... producing equivalent information, such as text alternatives for images and auditory descriptions of video, can be one of the most challenging aspects of Web design, and authoring tool developers should attempt to facilitate and automate the mechanics of this process. For example, prompting authors to include equivalent alternative information such as text equivalents, captions, and auditory descriptions at appropriate times can greatly ease the burden for authors. **Where such information can be mechanically determined and offered as a choice for the author (e.g., the function of icons in an automatically-generated navigation bar, or expansion of acronyms from a dictionary), the tool can assist the author.** At the same time, the tool can reinforce the need for such information and the author's role in ensuring that it is used appropriately in each instance." http://www.w3.org/TR/WAI-AUTOOLS/#gl-prewritten-descs (** Emphasis mine **) At the same time: UAAG (User Agent Authoring Guidelines) Techniques states: "Allow configuration to provide access to each piece of unrendered conditional content[1] "C". When a specification does not explain how to provide access to this content, do so as follows: If C is a summary, title, alternative, description, or expansion of another piece of content D, provide access through at least one of the following mechanisms: (1a) render C in place of D; (2a) render C in addition to D; (3a) provide access to C by allowing the user to query D. In this case, the user agent must also alert the user, on a per-element basis, to the existence of C (so that the user knows to query D); and (4a) allow the user to follow a link to C from the context of D. Otherwise, provide access to C through at least one of the following mechanisms: (1b) render a placeholder for C, and allow the user to view the original author-supplied content associated with each placeholder; (2b) provide access to C by query (e.g., allow the user to query an element for its attributes). In this case, the user agent must also alert the user, on a per-element basis, to the existence of C; and (3b) allow the user to follow a link in context to C." http://www.w3.org/TR/UAAG10/guidelines.html#tech-doc-content-access [1] Where conditional content is: "...Conditional content is content that, by format specification, should be made available to users through the user interface, generally under certain conditions (e.g., based on user preferences or operating environment limitations). Some examples of conditional content mechanisms include: The alt attribute of the IMG element in HTML 4. According to section 13.2 of the HTML 4 specification ([HTML4]): "User agents must render alternate text when they cannot support images, they cannot support a certain image type or when they are configured not to display images."..." http://www.w3.org/TR/UAAG10/glossary.html#def-conditional-content As well as: "Allow configuration to generate repair text when the user agent recognizes that the author has not provided conditional content required by the format specification. Sufficient techniques The user agent may satisfy this checkpoint by basing the repair text on any of the following available sources of information: URI reference (as defined in [RFC2396], section 4), content type, or element type. Note, however, that additional information that would enable more helpful repair might be available but not "near" the missing conditional content. For instance, instead of generating repair text on a simple URI reference, the user agent might look for helpful information near a different instance of the URI reference in the same document object, or might retrieve useful information (e.g., a title) from the resource designated by the URI reference." http://www.w3.org/TR/UAAG10/guidelines.html#tech-missing-alt So you see, the WAI have already thought about, discussed, and codified current specifications and techniques on this particular topic. Seems to me, the question is closer to: "should the HTML5 Standard reference this material?" Here I say yes. > > Matt is the one who provided the change proposal, and will defer to > him. "I would support a statement that makes reference to UAAG requirements on missing @alt." - Matt May http://lists.w3.org/Archives/Public/public-html/2010Jan/1103.html "Since there is such potential to conflate author advice with UA advice, I would much rather put repair techniques in a section of its own. Since the outcome of any repair techniques would vary from browser to browser, it's a set of recommendations that may help UAs further assist users, but would completely confound authors who might expect behavior where it may not yet exist. If further down the line browsers can agree on a given heuristic and commit to one technique working in a standard manner in all supporting browsers, it can be moved back to a normative section." - Matt May http://lists.w3.org/Archives/Public/public-html/2010Jan/1107.html In the interest of clarity I both agree and support these statements; especially the first one. > But I hope that we don't get into the habit of going outside > the boundaries of what should be included within an HTML > specification. Hinting to user agents that they should provide this > information, if they can, just ensures that we'll most likely have > inconsistent implementation--not to mention the possibility of > providing incorrect, or even muddled information. Shelley, user-agents are already told to do so, as the UAAG quote above details. I think the real question is should this information *also* be embedded into the HTML5 Standard, and I think that both Matt and I are suggesting no. There are appropriate places for this information, and in particular I believe that "Techniques" document(s) is the appropriate place, as future emergent techniques may in fact surface that we cannot envision at this time. Having a "locked-down" Standard that points to an evolutionary Techniques document is, to me, a huge win for both 'camps', as the standard does not need to be re-opened to accommodate technology advances we cannot envision, and such future techniques have a welcoming 'home' that is directly referenced from the standard, which further benefits authors, user-agents, and most importantly users. > > Then there's the issue of performance -- authoring tools only have to > try to determine the alt text once. ...according to...? I don't see that in the ATAG anywhere, but it's possible that I missed it. Reference URLs are always helpful. > Do we really want every user agent > to attempt the same process every time the web page is opened? For > every image? The alternative being? (And I don't have an answer here either) I think that the fundamental question posed by this thread is, should the HTML5 Standard: a) Provide duplicate information along with un-proven suggestions ('heuristics') as 'repair' techniques? b) Point to existing and evolving guidelines and techniques as the appropriate place for further 'details'? c) Do nothing/say nothing? (unless I've been totally distracted the past 2 weeks, which is also very possible) JF
Received on Sunday, 24 January 2010 04:38:16 UTC