- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Tue, 14 Sep 2010 09:53:31 +0100
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: public-html-a11y@w3.org
- Message-ID: <AANLkTi=Of-fTjCysq38FAS=FwN0VUoxnNgSX3M7U_XeW@mail.gmail.com>
Hi Ben, you wrote: "The elephant is still in the room!" I have no problem with the use of CSS to display images, if the UI is still understandable and usable by people who cannot access or understand those images. What a do have a problem with is making the default role of <img> something other than img, because in many cases it is an image, and users should be given the opportunity to have that information provided to them. Can't the same thing can be argued for table/tr/td elements? Table structures are widely used for purposes other than marking up data therefore they should not be mapped to the corresponding roles in accessibility APIs Now if HTML5 were to define a set for classifications for images that could be passed through to accessibility APIs as a property of the img I would see that as a step forward. example: <img type="photograph" alt="president obama sitting in the Oval office havinga cup of tea"> <img type="logo" alt="W3C"> accessibility API info: name= president obama sitting in the Oval office havinga cup of tea role="img" type="photograph" Then AT could provide the user with preferences to filter images based on type. you wrote: "From an end-user perspective what is the difference between these two cases?" there is no difference if you are using a user agent that supports CSS. you wrote: "In an editing scenario, might not the user also want access to the following presentational "img", even though ARIA excludes it from the accessible tree?" i would imagine so. regards stevef On 14 September 2010 08:48, Benjamin Hawkes-Lewis < bhawkeslewis@googlemail.com> wrote: > On 13 Sep 2010, at 13:42, Steven Faulkner wrote: > > No, because an inline <img> element is being used in the other example, > in this example it's not. > > The elephant is still in the room! > > From an end-user perspective what is the difference between these two > cases? In both scenarios, there's an image button with a text equivalent. > That one case uses "img" and another CSS is, from their perspective, a mere > implementation detail. If we're saying users need access to UI images, how > do users get access to that CSS generated image? > > > An example where it would be useful: > > > > > > <button contenteditable="true"><img src="cross.gif" alt="wrong" > width="94" height="85" border="0" ></button> > > > > In IE for example when contenteditable="true" it is recognised as a > graphic by JAWS and the img object information is provided to the user. > > > > Any html editor that provides a preview mode or wysywig editor. > > Thank you - that's an interesting use case. > > In an editing scenario, might not the user also want access to the > following presentational "img", even though ARIA excludes it from the > accessible tree? > > <button contenteditable="true"> > <img role="presentation" src="cross.gif" alt=""> > Wrong > </button> > > ARIA may need some additions to cover this use case. > > However, I'm not sure editable DOM trees are a safe guide to how normal DOM > trees should be mapped to the accessible tree. > > -- > Benjamin Hawkes-Lewis > > -- 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, 14 September 2010 08:54:26 UTC