Follow-up to: #1168246-136: Freedom For Fieldsets! Long Live The DETAILS.
Details should have ARIA added to them so that the open/closed state is semantically determinable:
http://wet-boew.github.com/wet-boew/demos/details/details-eng.html
<summary aria-expanded="false" aria-pressed="false" role="button" aria-controls="details-1" style="-moz-user-select: none;" tabindex="0">Example 2</summary>
<div style="display: none;">
<summary aria-expanded="true" aria-pressed="true" role="button" aria-controls="details-1" style="-moz-user-select: none;" tabindex="0">Example 2</summary>
<div style="display: block;">
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | Screen Shot 2013-01-02 at 9.41.52 AM.png | 589.89 KB | mgifford |
| #8 | core_details_aria_1848684.patch | 970 bytes | liam morland |
| #6 | core_details_aria_1848684.patch | 893 bytes | liam morland |
Comments
Comment #0.0
mgiffordbusted reference
Comment #1
mgiffordForgot to Tag
Comment #1.0
mgiffordreference link?
Comment #2
liam morlandAre @style and @tabindex really needed?
Does this element actually need ARIA? Shouldn't it be that the semantics communicated by ARIA are just replicating the inherent semantics of details/summary? Or is the ARIA a shim for browsers that don't understand details/summary?
The .details-description element should by the target of an @aria-describedby on the details element.
Comment #3
mgiffordI'm checking into it, but I'm sure
style="-moz-user-select: none;"was added to overcome something.Tabindex I'm less sure of. I'd prefer to leave out tabindex if we can.
I see this as the critical piece though:
aria-expanded="false" aria-pressed="false" role="button" aria-controls="details-1"aria-expanded="true" aria-pressed="true" role="button" aria-controls="details-1"More references:
https://github.com/wet-boew/wet-boew/wiki/Expandable-collapsible-content...
http://mathiasbynens.be/notes/html5-details-jquery
http://www.accessibleculture.org/articles/2012/03/screen-readers-and-det...
Comment #4
mgiffordtagging
Comment #5
mgiffordJust a note on the WET use of style/tabindex. It's used with polyfill not when native.
Polyfill uses tabindex to make unsupported element focusable, style to control visibility of contents and ARIA to add semantics.
Comment #6
liam morlandOK, but shouldn't it be in the core stylesheets, in that case?
So, should the polyfill JS add it then?
The other attributes are added by the attached patch.
Comment #8
liam morlandThe problem was undefined @id on the details. Is there a generic way of generating @id if one is not provided?
This version of the patch checks for @id and only creates @aria-controls if it is there.
Comment #9
mgiffordThis looks good. There are no visible differences in the UI. I don't know of a generic way to generate @id's if one doesn't exist.
The screenshot provides view in Firefox & Chrome with source.
Comment #10
webchickCommitted and pushed to 8.x. Thanks!
Comment #11
sunI'm not sure I understand why we continue to duct-tape our current implementation of non-native details, instead of working on the polyfill...?
This patch added role/aria attributes to summary elements, but the attributes are only set once on the server-side and never updated according to the actual state of a details/summary element. In other words, collapse.js was not updated accordingly.
Lastly, I've checked the referenced web sources, but I do not understand why we need to duplicate the semantic 'open' attribute with 'aria-*' attributes that essentially have the identical meaning? That's like adding a
role="link"attribute to every anchor tag on the page. Likewise, the summary element is to details as the legend element is to fieldsets - it is a clearly defined part of the spec and may only appear once within the parent container. I've the impression that we're trying to make screen reader implementations work that are broken in the first place...?Comment #12
mgiffordNoticing that we didn't address @Liam's point in #2:
"The .details-description element should by the target of an @aria-describedby on the details element."
@sun - I think that @Liam & I are just working with what we know. I understand in general what you've been trying to accomplish with polyfills, but it's harder for us to implement.
I don't know why in the examples used there was a replication of HTML5's open attribute & the aria-expanded="true". In general if it's defined in HTML5 semantically, it shouldn't be repeated in ARIA.
Comment #13
mgiffordFrom Paul Jackson I got insights as to why they are using both:
I don't think for D8 that we need to worry too much about non-HTML5 support. Not that there won't still be browsers that don't support HTML5. Not sure where to find a list of browsers that would need the WAI-ARIA. Searching for "open" within http://caniuse.com wasn't useful.
Comment #14
liam morlandPerhaps the polyfill should add the ARIA with JS. In other words, the HTML is pure HTML5 and JS adds whatever else is needed to make it work the same way for non-HTML5 user agents. On the other hand, how often is ARIA supported but not HTML5? Are we planning for a use case that doesn't exist?
Comment #15
mgiffordThat's what I thought too, but if you look at http://wet-boew.github.com/wet-boew/demos/details/details-eng.html with both Firefox & Chrome (using Inspect Element) you'll see that both modern browsers are handling this differently.
Firefox doesn't do anything with the markup. Chrome has native support. WET is use Modernizr's algorithm to determine support.
Comment #15.0
mgiffordUpdated issue summary.
Comment #16
mgifford@sun - let us know if you have ideas on how we can take this forward.
Comment #17
dom. commentedPatch #8 is wrong because it actually duplicates aria-expanded instead of aving both aria-expanded and aria-pressed. Also it does not adds the ="true" or ="false" which make it syntaxicly wrong at W3C. Finally it does not involve the JS to toogle those attributs to true/false.
I'm sorry I did not see this issue before, thus I'm working and submitting patch on this at :
#2472177: Collapsible fieldset have duplicated and wrong aria-expanded
(relatively to a META to have W3C validation everywhere in core)
Comment #18
mgiffordComment #19
Jeff Burnz commentedWhen you add role button to a non button element user agents will understand this to be a button and expect the space bar to be able to toggle it, however this will not work without extra JavaScript to detect use of the space bar key. I'm not so sure role button is a good idea.
I just ran into this when using an
<a>for my menu toggle and adding role=button. Instead I opted to just use a real button.https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Tec...
Comment #20
mgiffordWhere possible, using the correct semantic html5 element is always going to be better from what I've read.
Comment #29
ivan berezhnov commentedComment #36
quietone commentedI'm following up on issues that have been committed and re-opened.
This issue was committed to Drupal 8.x in Jan 2013 and re-opened in #11 due to questions about the implementation. The last discussions were 6 years ago.
Is there anything still to do here? If so, update the Issue Summary and add a comment.
Thanks
Edit: fix typo
Comment #38
quietone commentedThere hasn't been any further information provided so I am restoring the Fixed status, originally set in #10, because it was committed to Drupal 8.
Cheers.