Skip to content
This repository has been archived by the owner. It is now read-only.

Allow figcaption anywhere in a figure element? #177

Closed
chaals opened this issue Apr 7, 2016 · 13 comments

Comments

@chaals
Copy link
Collaborator

commented Apr 7, 2016

@chaals chaals added the needs tests label Apr 7, 2016

@LJWatson LJWatson changed the title Allow figcatpion anywhere in a figure element? Allow figcaption anywhere in a figure element? Apr 7, 2016

@LJWatson

This comment has been minimized.

Copy link
Collaborator

commented Apr 7, 2016

Test case:
http://ljwatson.github.io/test-cases/figcaption/index.html
On Windows, Chrome, Edge, Firefox and IE (11) render the <figcaption> based on its position in the DOM. It does not appear to be necessary for it to be the first/last child of <figure>.

@LJWatson

This comment has been minimized.

Copy link
Collaborator

commented Apr 8, 2016

IE (MSAA) does not support <figure> or <figcaption> (referenced from html5accessibility.com). Firefox and Chrome (IA2) expose the <figcaption> as the accessible name for the <figure>, regardless of where the <figcaption> is located within the <figure>.

Ping @stevefaulkner for confirmation and additional results.

chaals pushed a commit to chaals/testcases that referenced this issue Apr 8, 2016

chaals
figure / figcaption test
Does `figure` work for providing text alternatives?

Does placement of `figcaption` matter? See
w3c/html#177 for a motivation

@travisleithead travisleithead self-assigned this Apr 8, 2016

@travisleithead

This comment has been minimized.

Copy link
Member

commented Apr 8, 2016

Let me work up a PR for this

@travisleithead

This comment has been minimized.

Copy link
Member

commented Apr 8, 2016

OK. Feedback on the PR please.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 8, 2016

More tests and some preliminary results: http://chaals.github.io/testcases/figcaption-anywhere.html

@chaals

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 9, 2016

This presumably should be synched with ARIA accessible name calculation... @stevefaulkner?

@stevefaulkner

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2016

@chaals @LJWatson the acc name calculation will not be effected by the position of <figcaption> within the <figure> subtree, so no change in name calc required, me thinks.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 9, 2016

I was wondering what happens if there is more than one <figcaption>. In my tests, all of them are included, along with all the alt values. Is that according to spec, or are implementations doing something different to what ARIA says?

@LJWatson

This comment has been minimized.

Copy link
Collaborator

commented Apr 9, 2016

@chaals
"I was wondering what happens if there is more than one  

 . In my tests, all of them are included, along with all the  alt  values. Is that
according to spec, or are implementations doing something different to what ARIA says?"

Included in what? AFAIK only the <figcaption> should be used as the accessible name for the <figure>. The alt provides the accessible name for the <img>.

The HTML spec says there should only be one <figcaption> (either before or after flow content) within a <figure>.http://w3c.github.io/html/grouping-content.html#the-figure-element

If it seems there is implementation support for multiple <figcaption> elements within a <figure>, we should probably open a separate HTML issue and verify.

There is no figcaption role in ARIA, but ARIA 1.1 introduces the figure role:
https://www.w3.org/TR/wai-aria-1.1/#figure

An object with the figure role can have its accessible name provided using aria-label or aria-labelledby. The latter can take content from multiple sources, which seems to be the approximate equivalent of multiple <figcaption> elements in the native case.

@chaals

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 9, 2016

If it seems there is implementation support for multiple

elements within a , we should probably open a separate HTML issue and verify.

I'll run my tests on Windows today, but as far as Mac goes, anything I found that supports figcaption supports multiple ones. And for the PR #179 to address this we're talking about a couple of words, so I think we can handle it within the scope of this issue.

Included in what? AFAIK only the <figcaption> should be used as the accessible name for the <figure>. The alt provides the accessible name for the <img>.
[...]
[In ARIA 1.1] An object with the figure role can have its accessible name provided using aria-label or aria-labelledby. The latter can take content from multiple sources, which seems to be the approximate equivalent of multiple <figcaption> elements in the native case.

I agree that only the <figcaption> (or collection of them) should be used for figures. The problem is that I have yet to find an implementation that does that. But that's partly an ARIA question - although what we state as "the figure means whatever the figcaption says" is a restatement of the name calculation, and they should be in synch with each other and reality.

@stevefaulkner

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2016

@LJWatson the test case which has <figcaption> inside a <p> element is not practical as

is closed when the parser encounters the <figcaption>. So you end up with 2 <p>'s
live dom view

first figure has figcaption inside p, second has p then figcaption, then another p.
first does not parse as expected.

@LJWatson

This comment has been minimized.

Copy link
Collaborator

commented Apr 11, 2016

@stevefaulkner

Good catch, thanks. Have updated the test case.

@chaals chaals added this to the HTML5.1 WD (May 2016) milestone Apr 14, 2016

@chaals

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 25, 2016

fixed by #179

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
4 participants
You can’t perform that action at this time.