[whatwg] ARIA semantics of implied rows
Hi WHATWG, §4.9.12 Processing model ( https://html.spec.whatwg.org/multipage/tables.html#processing-model-3 ) currently states: A *row* is a complete set of slots from x=0 to x=x_width-1, for a particular value of y. Rows usually correspond to tr elements, though a row group can have some implied rows at the end in some cases involving cells spanning multiple rows. I am thinking that implied rows refers to cases such as: table id=theTable border=1 tbody tr td rowspan=10 colspan=3These are the first 10 rows./td /tr /tbody tbody tr tdRow 11, Column 1/td tdRow 11, Column 2/td tdRow 11, Column 3/td /tr tr tdRow 12, Column 1/td tdRow 12, Column 2/td tdRow 12, Column 3/td /tr tr tdRow 13, Column 1/td tdRow 13, Column 2/td tdRow 13, Column 3/td /tr tr tdRow 14, Column 1/td tdRow 14, Column 2/td tdRow 14, Column 3/td /tr tr tdRow 15, Column 1/td tdRow 15, Column 2/td tdRow 15, Column 3/td /tr /tbody /table .. where because the first row group has a TD spanning 10 rows but only one TR, there are 9 implied rows in that row group. As specified by WAI-ARIA 1.0: The HTML Working Group is incorporating WAI-ARIA into HTML 5. Official support for WAI-ARIA in HTML will be provided in that specification. This DTD is made available only as a bridging solution for applications requiring DTD validation but not using HTML 5. http://www.w3.org/TR/wai-aria/appendices#html_dtd One issue is that the ARIA semantics for implied rows are not defined. Currently, browsers that I have tested (Chrome 37.0.2062.124, Firefox 32.0.3, Safari 7.1, and Internet Explorer 11) only expose 6 rows for the example listed above. In order to get all 15 rows exposed to assistive technologies, I need to insert empty TR elements for the implied rows. It would be very useful if implied rows were exposed implicitly, using the same role as the row containing the anchor slot of the first cell in the implied row. Sincerely, Daniel Trebbien
Re: [whatwg] ARIA semantics of implied rows
On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: http://www.w3.org/TR/wai-aria/appendices#html_dtd DTDs have nothing to do with what you're seeing here. They're best ignored. One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? -- https://annevankesteren.nl/
Re: [whatwg] ARIA semantics of implied rows
(sorry, forgot to copy the list) On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: ... One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? The issue is that, as far as I can tell, HTML 4.01 does not support implied rows: http://www.w3.org/TR/html401/struct/tables.html This is new to HTML5. WAI-ARIA does define roles for a table (grid, row, rowgroup, gridcell, etc.), but you can't specify the role and state attributes for HTML5 implied rows. I ran through the forming a table steps ( https://html.spec.whatwg.org/multipage/tables.html#forming-a-table ) on paper for the example and I came up with x_width is 3 and y_height is 15. If the table model has 3 columns and 15 rows (9 of which are implied), then browsers should expose 3 columns and 15 rows.
Re: [whatwg] ARIA semantics of implied rows
On Fri, Sep 26, 2014 at 11:39 AM, Daniel Trebbien dtrebb...@gmail.com wrote: On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? The issue is that, as far as I can tell, HTML 4.01 does not support implied rows: http://www.w3.org/TR/html401/struct/tables.html This is new to HTML5. No, HTML4 supported this; it probably didn't actually have any normative text around it, but browsers certainly supported having a rowspan go past the end of the explicit rows. ~TJ
Re: [whatwg] ARIA semantics of implied rows
On Fri, Sep 26, 2014 at 3:01 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Sep 26, 2014 at 11:39 AM, Daniel Trebbien dtrebb...@gmail.com wrote: On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? The issue is that, as far as I can tell, HTML 4.01 does not support implied rows: http://www.w3.org/TR/html401/struct/tables.html This is new to HTML5. No, HTML4 supported this; it probably didn't actually have any normative text around it, but browsers certainly supported having a rowspan go past the end of the explicit rows. That's true. Browsers supported this. What I mean is that HTML4 didn't have normative specification of this, but HTML5 does. I guess what I wanted to clarify is that when a browser exposes a table to the operating system's accessibility layer which screen readers use to announce the content of a web page, the model of the table in the accessibility layer should match the HTML5 table model. Using the Accessibility Inspector tool on Mac and the Inspect tool on Windows, I am seeing that browsers are currently not exposing the implied rows. Chrome, Firefox, Safari, and Internet Explorer are only exposing 6 rows for the example. Using the example table HTML in Chrome for Mac, Chrome is not exposing to Mac's accessibility hierarchy the 15 rows of the table, but only 6 rows; there are only 6 AXRow children of the AXTable. With Accessibility Inspector I see that the AXCell corresponding to the first cell in the first row has the AXColumnIndexRange attribute set to loc=0, len=3 and the AXRowIndexRange attribute set to loc=0, len=10 (which are correct). However, when I navigate to the Row 11, Column 1 cell, VoiceOver announces row 2 of 6 Row 11, Column 1. If I modify the example HTML to insert empty TR elements for each of the 9 implied rows: table id=theTable border=1 tbody tr td rowspan=10 colspan=3These are the first 10 rows./td /tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr /tbody tbody tr tdRow 11, Column 1/td tdRow 11, Column 2/td tdRow 11, Column 3/td /tr tr tdRow 12, Column 1/td tdRow 12, Column 2/td tdRow 12, Column 3/td /tr tr tdRow 13, Column 1/td tdRow 13, Column 2/td tdRow 13, Column 3/td /tr tr tdRow 14, Column 1/td tdRow 14, Column 2/td tdRow 14, Column 3/td /tr tr tdRow 15, Column 1/td tdRow 15, Column 2/td tdRow 15, Column 3/td /tr /tbody /table .. then when I navigate to the Row 11, Column 1 cell, VoiceOver announces row 11 of 15 Row 11, Column 1. Also, Chrome then exposes 15 AXRow children of the AXTable. Using the original example in Internet Explorer 11, IE11 is exposing only 6 rows like Chrome, Safari, and Firefox; with the Windows SDK Inspect tool, I see that the UIA_TableControlTypeId has the Grid.RowCount attribute set to 6. Switching on Narrator, when I navigate to the Row 11, Column 1 cell, Narrator announces Row 11, Column 1. Column 1 row 2 item. Using the modified HTML containing the 9 empty TR elements, the Grid.RowCount attribute is set to 15 and Narrator will announce Row 11, Column 1. Column 1 row 11 item for the Row 11, Column 1 cell. I am fairly certain that the model of the table that browsers expose to the accessibility layer should match the HTML5 table model, but I wanted to confirm. Also, I wanted to ask what the ARIA semantics of the implied rows are. For example, suppose I have this (admittedly contrived): table border=1 tbody tr aria-selected=true role=row td rowspan=5Spans 5/td tdnbsp;/td tdnbsp;/td tdnbsp;/td /tr tr aria-disabled=true role=presentation td rowspan=4Spans 4/td tdnbsp;/td tdnbsp;/td /tr tr aria-hidden=true role=row td rowspan=3Spans 3/td tdnbsp;/td /tr tr aria-busy=true role=presentation td rowspan=2Spans 2/td /tr /tbody /table There is 1 implied row in this example, but what are the ARIA state attributes of this implied row? Is it selected and/or disabled and/or hidden and/or busy? What is the implied row's role? There should probably be a requirement that ARIA roles and state should be consistent.
Re: [whatwg] @aria-labelledby | Re: @generator-unable-to-provide-required-alt, figure with figcaption
Am 19.06.2013 um 20:53 schrieb Ian Hickson: [...] I've changed the spec to make figure applicable to your use case as well, and added more text to explain various use cases and whether they apply to figure. Let me know if the new text is still problematic for your use case. I agree that it would be overly restrictive to limit figure in the case you are presenting. The new text (http://html5.org/r/7991) covers my use case very well. I have updated the markup generator to use figures with figcaption. (d) The img element has a (non-conforming) generator-unable-to-provide-required-alt attribute whose value is the empty string.^[3] Well, that is an option for any use case a markup generator runs into. But it seems unattractive in all its verbosity to me. It's supposed to be a little unattractive, to discourage authors from using it to silent validators complaining about their hand-written pages (where they should just provide the fricking replacement text). Unfortunately -- although its verbosity is there to prevent any misunderstanding for its use -- it might leave the impression that a generator writing img src=... generator-unable-to-provide-required-alt= is not as good as a generator writing img src=... alt=an image Indeed. I don't know of a way to fix that. It's always going to be the case that a generator doing the wrong thing in a way that is machine-readably indistinguishable from the right thing is more likely to look correct at a quick glance than a generator that is doing the wrong thing in a machine-detectable way. I don't know what we can do about that. I'm open to suggestions. I see. Unfortunately I do not have a better idea. I have updated the markup generator to use generator-unable-to-provide-required-alt for the rare cases when it does not have a caption either. [...] In my case it is not applicable anyway: The converter generates markup for instant display -- the output is not saved to be edited. Doesn't mean that it's not still bad that it's inaccessible, of course. :-) Yep, a missing alt attribute is a missing alt attribute. Thanks a lot Martin
Re: [whatwg] @aria-labelledby | Re: @generator-unable-to-provide-required-alt, figure with figcaption
Am 17.06.2013 um 22:58 schrieb Ian Hickson: On Mon, 17 Jun 2013, Martin Janecke wrote: Am 17.06.2013 um 11:35 schrieb Steve Faulkner: the restriction on figure/figcaption is only in the whawtg spec not the W3C HTML spec as it was not deemed a useful or practical restriction when reviewed by the HTML WG. Sounds lovely, this would indeed solve my use case. Could you elaborate on what your use case and why it's not handled? Yes. The use case begins with a markup generator that does not have a suitable alt-text for images. In my case it's actually a converter converting some light-weight markup to HTML, but I don't think the discussion should dive into the details too deep as it applies to other markup generators as well -- I named WYSIWYG editors and automatic digitizers as examples. It is an established fact that there are markup generators that don't have a suitable image description for the required alt attribute.^[1] Without the required alt-attribute the generator's output is non-conforming or invalid markup. It seems that (or at least markup generator creators seem to think that) a notable amount of users prefer generators that produce output which passes conformance checker tests over those which produce output that gets big red error marks. This can pressure markup generator creators to trick conformance checkers into thinking their output was conforming. Methods to achieve this include using bogus alt-texts or empty alt-texts, suggesting a purely presentational image when it's actually not. These methods are in a way successful as conformance checkers today fall for the tricks. However, these tricks are considered harmful for accessibility. This motivated defining circumstances under which conformance checkers should silently ignore missing alt attributes.^[2] I'll now go through this list from the WHATWG spec to discuss where they cover and where they do not cover my use case, hopefully making my use case clearer in the process: (a) The img element has a title attribute with a value that is not the empty string (also as described above).^[3] A title attribute text is usually not available to the light-weight markup converter I maintain. This applies to other markup generators as well: An OCR digitizer does not find something equivalent to the typical implementation of the title attribute (i.e. a mouse-over text) in a book scan. While my markup generator usually has access to a caption for an image that is immediately visible to anyone and which could theoretically be included as title attribute, that would mean redundant text as in the following example: divimg src=tree.jpg title=Tree in Fantasia Tree in Fantasia/div I've actually seen captions re-used for title or alt attributes like this quite often in the wild. I do not consider this a desirable output. Why should visually impaired persons have to read everything twice? --- (b) The img element is in a figure element that …^[3] has a figcaption So now to the question: I don't understand why figure as defined in the WHATWG spec doesn't work for your case. What does the page look like? The problem for markup generators is that they do not understand how the pages look like exactly. My light-weight markup converter has to use solutions that work in many cases, favorable and less favorable ones. Again, this applies to other markup generators as well. They don't understand the semantics implied in the text they handle. I'll provide two examples in pseudo code -- the task for the markup generator is to translate it into HTML. Example 1: | The funny finch is a well known bird of Fantasia. | | [fig src=funny-finch.jpg]Fig 1.: Funny finch on a fig twig[/fig] | | It frolics freely in Fantasias famous forests. | | [fig src=feeding.jpg]Fig. 2.: Funny finch feeding a fledgling[/fig] | | The funny finch feeds on fruits and flies (fig. 2). Thanks to | reforestation, the funny finch population has flourished in the past | fourty years (fig. 3). | | [fig src=demographics.png]Fig. 3: Finch population 1970--2010[/fig] | | The funny finch is closely related to the freaky finches of Florida. The figure element with a figcaption is perfectly suitable for the images in example 1. Let's look at example 2: | The funny finch is a well known bird of Fantasia. | | [fig src=funny-finch.jpg]Funny finch on a fig twig[/fig] | | It frolics freely in Fantasias famous forests. | | [fig src=feeding.jpg]Funny finch feeding a fledgling[/fig] | | The funny finch feeds on fruits and flies, as shown in the photograph | above. Thanks to reforestation, the funny finch population has | flourished in the past fourty years, which the following diagram | illustrates. | | [fig src=demographics.png]Finch population 1970--2010[/fig] | | The funny finch is closely related to the freaky finches of Florida. Example 2 is conveying the same message as example 1. They almost look the same. However, while moving all the figures to the
Re: [whatwg] @aria-labelledby | Re: @generator-unable-to-provide-required-alt, figure with figcaption
On Wed, 19 Jun 2013, Martin Janecke wrote: Am 17.06.2013 um 22:58 schrieb Ian Hickson: On Mon, 17 Jun 2013, Martin Janecke wrote: Am 17.06.2013 um 11:35 schrieb Steve Faulkner: the restriction on figure/figcaption is only in the whawtg spec not the W3C HTML spec as it was not deemed a useful or practical restriction when reviewed by the HTML WG. Sounds lovely, this would indeed solve my use case. Could you elaborate on what your use case and why it's not handled? Yes. The use case begins with a markup generator that does not have a suitable alt-text for images. In my case it's actually a converter converting some light-weight markup to HTML, but I don't think the discussion should dive into the details too deep as it applies to other markup generators as well -- I named WYSIWYG editors and automatic digitizers as examples. It is an established fact that there are markup generators that don't have a suitable image description for the required alt attribute.^[1] Agreed. Without the required alt-attribute the generator's output is non-conforming or invalid markup. More importantly, it's not accessible markup. That is why it's not conforming. It seems that (or at least markup generator creators seem to think that) a notable amount of users prefer generators that produce output which passes conformance checker tests over those which produce output that gets big red error marks. This can pressure markup generator creators to trick conformance checkers into thinking their output was conforming. Methods to achieve this include using bogus alt-texts or empty alt-texts, suggesting a purely presentational image when it's actually not. Indeed. That's why we added the non-conforming but validator-silencing attribute generator-unable-to-provide-required-alt. These methods are in a way successful as conformance checkers today fall for the tricks. However, these tricks are considered harmful for accessibility. Right. (a) The img element has a title attribute with a value that is not the empty string (also as described above).^[3] A title attribute text is usually not available to the light-weight markup converter I maintain. This applies to other markup generators as well: An OCR digitizer does not find something equivalent to the typical implementation of the title attribute (i.e. a mouse-over text) in a book scan. While my markup generator usually has access to a caption for an image that is immediately visible to anyone and which could theoretically be included as title attribute, that would mean redundant text as in the following example: divimg src=tree.jpg title=Tree in Fantasia Tree in Fantasia/div I've actually seen captions re-used for title or alt attributes like this quite often in the wild. I do not consider this a desirable output. Why should visually impaired persons have to read everything twice? Indeed, this would not be good usage. That's what figure/figcaption is intended to avoid. (b) The img element is in a figure element that …^[3] has a figcaption So now to the question: I don't understand why figure as defined in the WHATWG spec doesn't work for your case. What does the page look like? The problem for markup generators is that they do not understand how the pages look like exactly. My light-weight markup converter has to use solutions that work in many cases, favorable and less favorable ones. Again, this applies to other markup generators as well. They don't understand the semantics implied in the text they handle. I'll provide two examples in pseudo code -- the task for the markup generator is to translate it into HTML. Example 1: | The funny finch is a well known bird of Fantasia. | | [fig src=funny-finch.jpg]Fig 1.: Funny finch on a fig twig[/fig] | | It frolics freely in Fantasias famous forests. | | [fig src=feeding.jpg]Fig. 2.: Funny finch feeding a fledgling[/fig] | | The funny finch feeds on fruits and flies (fig. 2). Thanks to | reforestation, the funny finch population has flourished in the past | fourty years (fig. 3). | | [fig src=demographics.png]Fig. 3: Finch population 1970--2010[/fig] | | The funny finch is closely related to the freaky finches of Florida. The figure element with a figcaption is perfectly suitable for the images in example 1. Indeed, this, apart from the lacking alternative text, is a good structure to use for the Web. Let's look at example 2: | The funny finch is a well known bird of Fantasia. | | [fig src=funny-finch.jpg]Funny finch on a fig twig[/fig] | | It frolics freely in Fantasias famous forests. | | [fig src=feeding.jpg]Funny finch feeding a fledgling[/fig] | | The funny finch feeds on fruits and flies, as shown in the photograph | above. Thanks to reforestation, the funny finch population has | flourished in the past fourty years, which the following diagram | illustrates.
Re: [whatwg] @aria-labelledby | Re: @generator-unable-to-provide-required-alt, figure with figcaption
Hi again, forgot to mention that the requirements for conformance checkers implementation requirements do differ due to differing the author requirement. so in W3C HTML validator: this results in an error img title=poot In validator.nu it doesn't -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 18 June 2013 12:02, Steve Faulkner faulkner.st...@gmail.com wrote: Hi Jonas I.e. is the difference between the W3C and WHATWG versions here just a difference in authoring requirements? Or also a difference in implementations requirements? authoring requirements only -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 18 June 2013 11:57, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 17, 2013 at 11:35 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Am 07.06.2013 um 23:13 schrieb Ian Hickson: img src=... title=image If you have a caption from the user (as opposed to replacement text), then this is a perfectly valid option. It's as valid as the figure case, and means the same thing. [...] the above statement is bad advice: browsers map title to the accessible name in accessibility APIs when alt is absent, so in the following cases: img src=... title=poot img src=... alt=poot the accessible name is 'poot'. it is only when there is an accessible name already provided that title is used as an accessible description: img src=... alt=poot title=description of poot Also note that as per the W3C HTML spec, use of the title without an alt is non conforming[1] as it does not represent a caption for an image and as you point out is hidden from a variety of users due to a long and consistent history of poor implementation. Steve, Does the spec still require that if an implementation encounters an image with a title but without an alt to present that to users with and without AT in a useful way? I.e. is the difference between the W3C and WHATWG versions here just a difference in authoring requirements? Or also a difference in implementations requirements? / Jonas
Re: [whatwg] @aria-labelledby | Re: @generator-unable-to-provide-required-alt, figure with figcaption
Am 17.06.2013 um 11:35 schrieb Steve Faulkner: Is there a chance that use of aria-labelledby is added to the spec (4.8.1.1.13 Guidance for markup generators, 4.8.1.1.14 Guidance for conformance checkers) as alternative to figure with figcaption or the title attribute? I'd like to suggest this. It does make equally sense in my opinion and I think I've described the use case in this thread: -- markup generator has no alt-text for an image -- image has a caption that should be immediately visible and possibly contain markup = no title attribute -- it is not known whether the image can be moved somewhere else in the document = no figure with figcaption the restriction on figure/figcaption is only in the whawtg spec not the W3C HTML spec as it was not deemed a useful or practical restriction when reviewed by the HTML WG. Sounds lovely, this would indeed solve my use case. I don't know how to asses that the restriction is dropped in a W3C draft but still included in the WHATWG version, though. Is this consensus and likely to become standard or still very uncertain territory? Regards Martin
Re: [whatwg] @aria-labelledby | Re: @generator-unable-to-provide-required-alt, figure with figcaption
On Mon, 17 Jun 2013, Martin Janecke wrote:
Am 17.06.2013 um 11:35 schrieb Steve Faulkner:
the restriction on figure/figcaption is only in the whawtg spec not
the W3C HTML spec as it was not deemed a useful or practical
restriction when reviewed by the HTML WG.
Sounds lovely, this would indeed solve my use case.
Could you elaborate on what your use case and why it's not handled?
I don't understand why figure as defined in the WHATWG spec doesn't work
for your case. What does the page look like?
I don't know how to assess that the restriction is dropped in a W3C
draft but still included in the WHATWG version, though. Is this
consensus and likely to become standard or still very uncertain
territory?
The W3C spec is a fork of the WHATWG standard. I can't speak for what
they're doing (and this would be the wrong list to discuss it, anyway). As
far as the WHATWG spec goes, we try to base decisions on use cases.
For figure, the idea is that it should be reasonable to style figure
with something like:
figure { float: right; }
If we don't say that figure's contents can be moved in this way, then
that becomes much less viable.
If what you want is just an inline image followed by some text, though,
you don't need figure or title= -- you can just put in the image and
the text, as in:
img src=the image !-- FIXME: replacement text is missing --
pMore text...
It's hard to know without looking at specific examples exactly what the
optimal markup should be, though.
On Mon, 17 Jun 2013, Steve Faulkner wrote:
Am 07.06.2013 um 23:13 schrieb Ian Hickson:
img src=... title=image
If you have a caption from the user (as opposed to replacement
text), then this is a perfectly valid option. It's as valid as the
figure case, and means the same thing.
the above statement is bad advice:
browsers map title to the accessible name in accessibility APIs when alt
is absent, so--
...so the browsers are buggy. This is not unusual. File bugs. :-) Indeed,
since you've demonstrated yourself able to write code, you could just go
and fix the bugs directly. :-)
Writing specs for the lowest-common-denominator is not the way we'll get a
usable, accessible Web. We might sometimes be forced to when there are
compat requirements with massively deployed content that Web author are
relying on that prevent certain behaviours from being fixed, but this
really doesn't apply in the case of ATs, since the vast majority of
authors have never tested how their pages work in ATs.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] @aria-labelledby | Re: @generator-unable-to-provide-required-alt, figure with figcaption
Am 07.06.2013 um 23:13 schrieb Ian Hickson: img src=... title=image If you have a caption from the user (as opposed to replacement text), then this is a perfectly valid option. It's as valid as the figure case, and means the same thing. [...] I don't know whether someones writes something like which the following figure illustrates instead of which is illustrated by fig. 3 somewhere in the text above a figure. But this difference decides whether using the figure element conforms with the spec. So a code generator can only use something which is structurally and optically identical to the figure element but does not have the theoretical requirement to be movable to a different place in the document, e.g.: div class=figure img src=... div class=caption.../div /div And here conformance checkers will complain about the missing alt-attribute again ... If you use img src=... title=... it'll work (and be correct, insofar as anything missing alt text can be correct). While the title attribute might be as good as the figcaption or a div-caption element in meaning, it differs in practice, as the element can include further markup, the attribute cannot. The title attribute is displayed as mouse-over text in most browsers whereas the figcaption is usually immediately readable to anyone, just as a caption for a picture in a book. I am aware that one could use JavaScript to make the text from the title attribute immediately visible as well. But this would require further technology on the reader’s side (JS) and complicate things more than justified for the cause, in my opinion. What my markup generator actually does with captioned images is this: meta name=generator content=generator-name … div class=figure img src=... aria-labelledby=caption-x div id=caption-x class=caption.../div /div (see also http://www.w3.org/WAI/GL/wiki/Using_aria-labelledby_to_provide_a_text_alternative_that_serves_the_equivalent_purpose) Is there a chance that use of aria-labelledby is added to the spec (4.8.1.1.13 Guidance for markup generators, 4.8.1.1.14 Guidance for conformance checkers) as alternative to figure with figcaption or the title attribute? I'd like to suggest this. It does make equally sense in my opinion and I think I've described the use case in this thread: -- markup generator has no alt-text for an image -- image has a caption that should be immediately visible and possibly contain markup = no title attribute -- it is not known whether the image can be moved somewhere else in the document = no figure with figcaption -- markup generator should not be pressured to use bogus alt-text to calm easily scared customers using validators E.g. OCR book digitizers or markup editors strictly following the WYSIWYG paradigm. Regards Martin (PS: Also, thank you and Jukka for your comments that I've not replied to.)
Re: [whatwg] ARIA
On Thu, 28 Feb 2008, Dave Hodder wrote: The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it should clarify the relationship (or non-relationship as it is at present), even if it's only a brief mention in section 1.1. There's a section on it now. On Fri, 29 Feb 2008, James Graham wrote: Unfortunately a brief mention is insufficient as aria functionality overlaps substantially with HTML functionality and so processing requirements for aria-in-html need to be carefully considered (so we can answer questions like how does div aria-role='heading' affect the outline algorithm). This has not yet happened. The answer is now it does not. ARIA doesn't appear to have enough expressive power to be affected by the outline algorithm much, either (it's intended for authors, so there's no way to express the nested implied sections with it). On Fri, 7 Mar 2008, Simon Pieters wrote: I would guess that it's the AT that would be the one to implement the outline algorithm. So if div role=heading is reported the same way as h1 is, then div role=heading does affect the document outline in the AT the same way as h1 affects the document outline. Otherwise, what is the AT supposed to do with the heading if not put it in the list of headings? Surprise the user when he stumbles upon it and say Oh snap, that's a heading right there! Didn't see that one coming.? :-) (BTW, I would be fine with solving this particular issue by dropping heading from ARIA -- I don't see what problem it is trying to solve that h1 doesn't.) I don't really see how to solve this issue from HTML5's side. On Fri, 7 Mar 2008, Aaron Leventhal wrote: [...] On the other hand for the landmark roles which specify semantics but not behavior, I would agree that sticking with HTML elements is a better approach. Even if there is associated behavior for them, such as a hotkey, they will degrade well to older user agents. Should I just say that you can't use these landmark roles on elements from HTML5 then? On Fri, 7 Mar 2008, James Graham wrote: OK, but we still need to specify what happens when they are used. To take the aria-role=heading example again, I believe it's a requirement that a page that uses that has the same outline structure when viewed using a tool that uses an accessibility API as it does when viewed through a tool that accesses the DOM directly. I don't know how to achieve this. On Tue, 11 Mar 2008, Aaron Leventhal wrote: In general these are great questions. The question as I understand it, should the spec spell out which role properties you get naturally with an HTML element, so an author knows if they even need to override them with ARIA in the first place? I've done that. Therefore input type=checkbox role=button This is non-conforming now, but will result in the element appearing to AT users as a regular button. (And I guess the user gets really confused if they try to activate it.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] ARIA
Jim Jewett wrote: I think the question is more about how the HTML elements themselves interact. For example,tr elements should probably be interpreted by default astr aria-role=row because that is part of the semantics of tr. In some cases, the default mapping will also depend on other attributes. (input type=checkbox vsinput type=reset) Ideally the specification would give a complete list of such defaults, because otherwise there will be at least a few disagreements. For example, it looks as thoughol should *not* have aria-role=list, but that isn't something I would have guessed from the names. In general these are great questions. The question as I understand it, should the spec spell out which role properties you get naturally with an HTML element, so an author knows if they even need to override them with ARIA in the first place? Do you mind asking this question on the wai-xtech list/ You can get subscribed to on an individual request basis -- just email me and I'll help you get on it. If you don't want to spend a lot of time, then please at least send your feedback to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] The next question is what to do when an author explicitly uses an aria attribute other than the default. For example, it is fairly common to hook javascript to a checkbox so that it acts like a command button. Therefore input type=checkbox aria-role=button should probably be treated as having both roles, but aria-role=presentation (or even a parent with aria-role=childrenArePresentational) should probably remove the default aria-roles This one is simpler. ARIA properties override the built-in semantics. You can use |role| on any element, such as input and it will override the natural role of the element. Therefore input type=checkbox role=button will be reported to assistive technologies as a button. The same thing applies to properties. ARIA properties have the last say when they conflict with the natural properties of an element. Overriding one property with ARIA does not affect the other properties on an element. These simple rules were found to be the most effective. There are a lot of sensible concerns. I've drafted a FAQ here with some more info, which I think addresses most concerns: http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ A Best Practices Guide and Primer are under development for authors. I am also working an implementors guide for user agents. Let me know if you want to see that. As aside: I noticed you refer to role as aria-role. The role attribute is the one ARIA attribute that doesn't need aria- as a prefix. It's a special attribute that is intended to address more than accessibility -- it's been argued already and unlikely to change because of currently shipping software. - Aaron
Re: [whatwg] ARIA
Aaron Leventhal wrote: James Graham wrote: Dave Hodder wrote: The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it should clarify the relationship (or non-relationship as it is at present), even if it's only a brief mention in section 1.1. Unfortunately a brief mention is insufficient as aria functionality overlaps substantially with HTML functionality and so processing requirements for aria-in-html need to be carefully considered (so we can answer questions like how does div aria-role='heading' affect the outline algorithm). This has not yet happened. Okay, so I can speak to this. I developed first browser implementation of ARIA -- the one in Firefox. ARIA doesn't really overlap with HTML, because ARIA only reports what a JS developer is using elements for. So ARIA semantics should not affect behavior. Any code for dealing with ARIA markup should be strictly in the accessibility API support code (MSAA/IAccessible2/ATK/AT-SPI/UI Automation/Universal Access). This seems like a poor idea from the point of view of authors actually using the markup correctly as they will have to use special accessibility-API aware tools to inspect the effects of their aria-* markup. A div need not affect the outline algorithm, etc. any more than a div does. Thus it should not be complicated to mention ARIA in the spec. So, given markup like: section h1foo/h1 div aria-role='heading'bar/div /section would AT questioned on what the headings and subheadings of the section are report on the h1 alone (as specified by the current outline algorithm)? Similarly, if I have a table like: trth id=a1/thth id=b2/th/tr trtdA/tdtd aria-describedby=aB/td/tr would AT report the cell headings for B as 2, not 1, despite the aria-describedby attribute? If the aria-* attributes overrule the HTML-native algorithms then aria creates an odd (and IMHO unpleasant) situation in which a document's semantics depend on the type of client being used to view it. What's the easiest way to test existing aria implementations on Mac/Linux (I don't have access to a Windows box)? -- Mixed up signals Bullet train People snuffed out in the brutal rain --Conner Oberst
Re: [whatwg] ARIA
Aaron Leventhal wrote: On the other hand for the landmark roles which specify semantics but not behavior, I would agree that sticking with HTML elements is a better approach. Even if there is associated behavior for them, such as a hotkey, they will degrade well to older user agents. OK, but we still need to specify what happens when they are used. To take the aria-role=heading example again, I believe it's a requirement that a page that uses that has the same outline structure when viewed using a tool that uses an accessibility API as it does when viewed through a tool that accesses the DOM directly. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] ARIA
James Graham wrote: What's the easiest way to test existing aria implementations on Mac/Linux (I don't have access to a Windows box)? Firefox 3 + Accessibility Extensions for Mozilla http://cita.rehab.uiuc.edu/software/mozilla/installation.php JF
Re: [whatwg] ARIA
On Fri, 07 Mar 2008 10:56:22 -0800, John Foliot [EMAIL PROTECTED] wrote: James Graham wrote: What's the easiest way to test existing aria implementations on Mac/Linux (I don't have access to a Windows box)? Firefox 3 + Accessibility Extensions for Mozilla http://cita.rehab.uiuc.edu/software/mozilla/installation.php On Mac, Opera 9.5 beta - latest weekly at http://my.opera.com/desktopteam With VoiceOver, you can set it to show what it is reading out as a transparent box on the screen. I find that very useful for testing. /me reaches across and slaps john with a wet fish, for not mentioning Opera ;) cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] ARIA
James Graham wrote: Dave Hodder wrote: The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it should clarify the relationship (or non-relationship as it is at present), even if it's only a brief mention in section 1.1. Unfortunately a brief mention is insufficient as aria functionality overlaps substantially with HTML functionality and so processing requirements for aria-in-html need to be carefully considered (so we can answer questions like how does div aria-role='heading' affect the outline algorithm). This has not yet happened. Okay, so I can speak to this. I developed first browser implementation of ARIA -- the one in Firefox. ARIA doesn't really overlap with HTML, because ARIA only reports what a JS developer is using elements for. So ARIA semantics should not affect behavior. Any code for dealing with ARIA markup should be strictly in the accessibility API support code (MSAA/IAccessible2/ATK/AT-SPI/UI Automation/Universal Access). A div need not affect the outline algorithm, etc. any more than a div does. Thus it should not be complicated to mention ARIA in the spec. - Aaron
Re: [whatwg] ARIA
Dave Hodder wrote: The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it should clarify the relationship (or non-relationship as it is at present), even if it's only a brief mention in section 1.1. Unfortunately a brief mention is insufficient as aria functionality overlaps substantially with HTML functionality and so processing requirements for aria-in-html need to be carefully considered (so we can answer questions like how does div aria-role='heading' affect the outline algorithm). This has not yet happened. -- Mixed up signals Bullet train People snuffed out in the brutal rain --Conner Oberst
[whatwg] ARIA (was: Re: Thoughts on HTML 5)
[EMAIL PROTECTED] wrote:
snip
As for my suggestion of reldata, my intent is to use the attribute for any type of data
related to the element. The role attribute is intended to be used (from my
understanding) to designate what role the element is playing on the page. This is not an
appropriate place to put extra data that isn't necessary for the rendering or understanding of the
element. My thought is doing something like this:
div id=whatever reldata={clicks:1,track:true}
The data format could be whatever someone wants, plain text, structured text,
JSON...whatever you need. The point is to have a common place to dump extra but
related data that isn't important to the understanding of the element. I often
use custom attributes for this now, but it would be nice to have an official
attribute for this purpose.
It sounds like the two attributes would be complementary, with role
defining the tag as a whateverwidget, and reldata describing the
initial state and properties of the widget.
I don't know if you've seen the recent Accessible Rich Internet
Applications http://www.w3.org/TR/wai-aria/ draft? (There's also a
primer at http://www.w3.org/TR/wai-aria-primer/.) It describes a
number of standard states that can be added to custom controls. Rather
than potentially fitting multiple values into a reldata attribute, it
defines a host of attributes beginning with aria-. Example:
span role=checkbox aria-checked=trueFoo/span
I believe a number of script libraries (Dojo for example) plan on
supporting ARIA. Firefox has some ARIA support already.
The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it
should clarify the relationship (or non-relationship as it is at
present), even if it's only a brief mention in section 1.1.
Regards,
Dave
