- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Mon, 7 Jun 2010 11:05:23 -0500
- To: Shelley Powers <shelleyp@burningbird.net>, Steven Faulkner <faulkner.steve@gmail.com>
- Cc: HTML WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi Shelley, Steve wrote: >> # when a figure has a <figcaption> the content of the <figcaption> >> should act as the accessible name for the image(s) inside the <figure> >> if the image(s) do not have a text alternative provided using the alt >> attribute. Shelley wrote: > Disagree, 100%. > > The figure element can have a dozen images, two tables, a code block or > two, paragraphs, and div elements. The figcaption names all of this, not > just the img element (s). > > The alt attribute must be provided regardless of figcaption, as figure > is defined now. Good catch Shelley. Okay, how about restricting it to: When a figure has an image as sole content use a <figcaption> as the accessible name for the image. But in scenarios of multiple images in a figure element alt rules apply. Thoughts? Thanks. Best Regards, Laura On 6/7/10, Shelley Powers <shelleyp@burningbird.net> wrote: > Steven Faulkner wrote: >> hi laura, >> we haven't discussed the <figure> element. >> >> my take on the figure element is that the >> # <figure> should be mapped to accessibility APIs as a grouping >> element like <p> or <div> >> > > There's a couple of issues with this. > > For one, there's an assertion in the HTML5 specification that the figure > element can be moved to another location, and there's an implied > connection between the material. A second assertion in the > counter-proposal gives the impression that figure elements can be > "skipped" and returned to later. > > Both are expectations that don't map to a normal grouping element, such > as div or p. In addition, if the figcaption element is not supplied, how > would we differentiate between figure and div and p? Or I should say, > how would UAs differentiate? >> # decorative images should not be allowed as content of a <figure> >> element as the HTML5 semantics imply that the content of the figure >> should be meaningful, so no <img alt=""> >> > > Agree, 100%. >> # when a figure has a <figcaption> the content of the <figcaption> >> should act as the accessible name for the image(s) inside the <figure> >> if the image(s) do not have a text alternative provided using the alt >> attribute. >> > Disagree, 100%. > > The figure element can have a dozen images, two tables, a code block or > two, paragraphs, and div elements. The figcaption names all of this, not > just the img element (s). > > The alt attribute must be provided regardless of figcaption, as figure > is defined now. > > >> #if the image(s) inside the figure have alt then the <figcaption> >> content could act as the accessible description unless for example the >> figcaption is referenced by an aria labelledby on an img: >> >> In this case the accessible name is "Dog on a bike. Chester can ride >> without using his paws." >> >> <figure> >> <img id="img1" alt="dog on a bike." aria-labelledby="img1 cap"> >> <figcaption id="cap"> Chester can ride without using his >> paws.</figcaption> >> </figure> >> >> In this case the accessible name is "Dog on a bike." and the >> accessible description is "Chester can ride without using his paws." >> >> > > Again, though, considering the fact that the figure element can contain > any number and types of elements, I don't think you can imply anything > about a direct figcaption to img association. > > I think each img element just has to live on its own, as if the > figcaption didn't exist. Unless, as you say, the aria-labelledby > attribute provides a more granular definition of the association between > the two. > >> <figure> >> <img id="img1" alt="dog on a bike." aria-labelledby="img1 cap"> >> <figcaption id="cap"> Chester can ride without using his >> paws.</figcaption> >> </figure> >> >> In this case the accessible name is "Chester can ride without using >> his paws." which I think is an unsatisfactory text alternative as it >> does not provide adequate information about what is depicted visually >> in the image. >> >> <figure> >> <img > >> <figcaption >Chester can ride without using his paws.</figcaption> >> </figure> >> >> while this would be better, but it is still currently problematic from >> a practical point of view as no browsers or AT provide the >> programmatic mapping between the <figcaption> and the img. So the >> accessible name provided through an accessibility API is "" >> >> > And technically, can't. Not with the current figure definition. >> <figure> >> <img > >> <figcaption>Chester the dog riding a bike without using his >> paws.</figcaption> >> </figure> >> >> Using aria-labelledby is better in this case because for users of >> AT/browsers that support aria-labelledby the programmatic association >> will be provided, >> <figure> >> <img aria-labelledby="cap"> >> <figcaption id="cap">Chester the dog riding a bike without using his >> paws.</figcaption> >> </figure> >> >> but again aria-labelledby is only supported by a subset of browsers/AT >> so the safest bet is to provide an adequate accessible name using alt >> attribute. >> >> > > Agree, 100%. > >> <figure> >> <img aria-describedby="cap" alt="dog on a bike"> >> <figcaption id="cap">Chester the dog riding a bike without using his >> paws.</figcaption> >> </figure> >> >> regards >> steve >> >> > > Shelley > >> On 6 June 2010 20:21, Laura Carlson <laura.lee.carlson@gmail.com> wrote: >> >>> Hi Shelley, >>> >>> >>>> I'm not sure how the accessibility API mapping would work, though I've >>>> seen the spec that provides User Agent instructions. However, from a >>>> ARIA to element mapping perspective, I'm not sure how figure and aside >>>> would map. >>>> >>> There is an ARIA mapping subgroup in the accessibility task force. I >>> think Steve heading that group. >>> >>> Steve, has the ARIA mapping group discussed the aside or figure elements? >>> >>> Thanks. >>> >>> Best Regards, >>> Laura >>> >>> On 6/6/10, Shelley Powers <shelleyp@burningbird.net> wrote: >>> >>>> Laura Carlson wrote: >>>> >>>>> Hi John, >>>>> >>>>> Shelley wrote: >>>>> >>>>> >>>>> >>>>>>> I appreciate her effort, but I believe that Sam has shut down the >>>>>>> discussion, which is a co-chair prerogative. I'm waiting resolution >>>>>>> on >>>>>>> several change proposals before I determine my next steps. >>>>>>> >>>>>>> >>>>> John wrote: >>>>> >>>>> >>>>> >>>>>> I don't think the chairs (Sam) has shut down any discussion at all - >>>>>> he >>>>>> has >>>>>> clearly given all a 'next-steps' roadmap that actually has two options >>>>>> - >>>>>> file bug reports with specific actionable items, as well as leaving >>>>>> the >>>>>> door >>>>>> open to a Formal Objection (with an apparent preference for bug >>>>>> reports >>>>>> first). >>>>>> >>>>>> >>>>> Thanks. I hope people have the time and the wisdom to do what is best. >>>>> >>>>> Creating elements that are inherently accessible, that provide >>>>> accessibility from the get-go, with no additional work by the author >>>>> is could be a win for accessibility. A mechanism to provide a native >>>>> aside element ala the WAI-ARIA "complimentary" landmark role is a good >>>>> idea. It could be applied to an area containing associated content. >>>>> >>>>> In the counter change proposal it says that the aside element >>>>> "expresses this semantic directly in the markup, allowing other types >>>>> of UAs to give their users similar ability to skip over irrelevant >>>>> content and return to it at their leisure". >>>>> >>>>> Do you think HTML5 specifies how devices are to interact with aside >>>>> and skip the content clearly enough? Do you see any flaws in the >>>>> specification of the aside element? >>>>> >>>>> >>>>> >>>> Not part of the group, but I wanted to respond to this question, and >>>> also explain why I said neither is accessible. Thanks for cc'ing me on >>>> the email, Laura. >>>> >>>> Some time back when we were discussing all of the new elements, I made a >>>> statement that so many new elements are going to be a burden on AT >>>> devices, too. At that time, one of the group members stated that rather >>>> than AT devices having to learn the new elements, such as "figure" and >>>> "aside", each would be mapped to the existing accessibility API by the >>>> browser companies, so they would be accessible "out of the box". >>>> >>>> This made a lot of sense to me, and is the reason I didn't include the >>>> elements being an additional burden on AT devices as an objection to >>>> figure and aside. >>>> >>>> However, seems to me for this to work, this accessibility mapping needs >>>> to be stated. Otherwise, each browser vendor could map the elements >>>> differently. Now, perhaps another spec is the place, but I would think >>>> that the HTML5 spec would be the better place, since it is the spec that >>>> originated the elements. >>>> >>>> I'm not sure how the accessibility API mapping would work, though I've >>>> seen the spec that provides User Agent instructions. However, from a >>>> ARIA to element mapping perspective, I'm not sure how figure and aside >>>> would map. For instance, if aside is treated as a typographical sidebar >>>> or note, there is an ARIA role of note that fits this use. However, if >>>> aside is treated as a web page sidebar, the more appropriate role is >>>> complementary. The two are not the same in ARIA, so we have to assume >>>> the two are not the same in the accessibility API, either. >>>> >>>> So, in my opinion, I don't believe aside, as currently defined in the >>>> HTML5 spec, is accessible. I'm not an accessibility expert, though. >>>> Perhaps the experts don't see this as a problem. >>>> >>>> Figure is another issue, as you have also noted. If figure really were >>>> captioning for a graphic, I think there could be a clean accessibility >>>> mapping, but because figure can include most anything, you start to have >>>> some interesting issues. >>>> >>>> And figures really aren't meant to be 'skipped' typographically. They're >>>> actually an important part of the content, but are managed differently >>>> because larger images may not fit well where they are needed within >>>> printed material. When people say, "See Figure ..." they really mean for >>>> folks to look at that figure -- it's complementary to the text. It >>>> clarifies and expands on the text. It's never meant to be skipped. >>>> >>>> I'm not sure how figure got redefined to something that can be skipped. >>>> From an accessibility perspective, though, if it's managed as something >>>> that can be easily skipped, those needing this functionality may end up >>>> with a less than ideal experience. They may actually _lose_ important >>>> information. >>>> >>>> In my read of the HTML5 spec, I don't see anything addressing these >>>> issues. I imagine this could be covered in another spec, but there's >>>> nothing detailing this, or providing a plan. >>>> >>>> Anyway, your questions are good. I failed to get the elements removed, >>>> and am concerned that this failure then meant that these elements were >>>> not going to be 'cleaned up'. I should have provided an alternative >>>> change proposal--keep the elements and redefine and clean them up--but I >>>> genuinely believe the ARIA approach to be the better one, and couldn't >>>> support an alternative I felt to be inferior. >>>> >>>> >>>>> Do you (or anyone else) see any ways in which the aside element should >>>>> be improved in HTML5? Or do you consider it okay as is? >>>>> >>>>> In regards to the figure/figcaption elements, there is no doubt that a >>>>> mechanism to explicitly provide a caption for an image is a good idea. >>>>> >>>>> Do you think that the figure/figcaption elements are specified >>>>> correctly? >>>>> >>>>> The majority of style guides disallow tables as content for a figure. >>>>> But HTML5 does not. It allows any flow content in the figure element >>>>> not just images. Do you think this present any problems? >>>>> >>>>> Do you anticipate nesting a table into figure causing any problems? >>>>> >>>>> Do you see any issues existing with a figcaption + table caption >>>>> scenario? A table caption is read by JAWS. Do you foresee a figcaption >>>>> to be read in the same way? When a table element is the only content >>>>> in a figure element other than the figcaption, the spec says that the >>>>> caption element should be omitted in favor of the figcaption do you >>>>> think this is speced correctly? >>>>> >>>>> Do you think that multiple tables in a figure element would be read >>>>> correctly? It seems that they should linearize, do you think would >>>>> that they would? >>>>> >>>>> The spec does not define how the figure is associated with the >>>>> original content. The counter proposal states, >>>>> >>>>> "Users interacting visually with the article can easily skip past this >>>>> content temporarily and avoid interrupting their reading of the main >>>>> article, and then return to the content to understand it when they >>>>> feel comfortable. Expressing this semantic directly in markup allows >>>>> alternative UAs to present their users with the same ability, thus >>>>> improving Accessibility." >>>>> >>>>> The spec does not say devices should have the ability to skip over the >>>>> figures, and return later, do you think that would be useful? The >>>>> figure element could be located outside of an article; it could be >>>>> located in another part of the web page, even another web page. It is >>>>> not specified how a connection between this physically separated >>>>> element is relate back to the original article element. Do you think >>>>> that the spec should specify how this is to be accomplished or >>>>> anything in this regards? >>>>> >>>>> Do you (or anyone else) see any ways in which the figure element >>>>> should be improved in HTML5? Or do you consider the element okay as >>>>> is? >>>>> >>>>> Thanks. >>>>> >>>>> Kindest regards, >>>>> Laura >>>>> >>>>> >>>>> >>>> Shelley >>>> >>>> >>>> >>> -- >>> Laura L. Carlson -- Laura L. Carlson
Received on Monday, 7 June 2010 16:06:01 UTC