Opened 8 years ago
Closed 7 years ago
#2670 closed defect (bug) (maybelater)
Plugin Theme: FAQ toggles only on button click
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Plugin Directory | Keywords: | has-screenshots ux-feedback a11y-feedback |
Cc: |
Description
In the FAQ Section the single dt
has cursor: pointer;
but the section is only actually toggled by clicking on the text/button
element. Clicks on the dt (including the pseudo before) are ignored.
I propose that the section is toggled by clicking anywhere on the dt
element.
Attachments (1)
Change History (9)
#1
@
8 years ago
- Keywords has-screenshots ux-feedback added
I agree the entire row should be clickable, especially since cursor: pointer
is set for the dt
element. It makes it appear as if the entire row is interactive, however only clicking the button
text actually expands the FAQ.
For accessibility, we should stick with the button
triggering the expansion, however it should be styled so as to fill the height and width of the FAQ row.
This ticket was mentioned in Slack in #accessibility by kevinwhoffman. View the logs.
8 years ago
#3
@
8 years ago
Chiming in by invitation :)
First of all I'd consider if using a definition list is really necessary. Some screen readers have limited support for <dl>
elements and they just get them as "list", sometimes announcing a wrong number of list items. See quick test here: http://codepen.io/afercia/full/PbQprv/
Rich semantics adds a real value when software can get it and pass the information to people using that software. If this is not the case, it's just an academic discussion :) In this case maybe it doesn't add a real value and I'd consider to simplify the markup. Yes, sometimes definition lists make styling easier, but that's not a valid reason to choose a dl.
I'd agree that the "arrow" should be clickable. Maybe just moving the CSS generated icon inside the button and adjusting the CSS would be enough.
However, the CSS generated icon should be wrapped within a span
element and hidden from assistive technologies using aria-hidden="true"
. That's because some AT do try to announce the CSS generated content, as this is what the CSS 3 spec says.
There are 2 aria-expanded
attributes. The first one is on the dt
element, the second one on the button. The former is a bit pointless since the dt
is not focusable so it won't be announced. By the way, it's the only one that updates its value. Instead, the aria-expanded
on the button is announced but it's always false
.
Screenshots:
The question is expanded but aria-expanded is still false, thus screen readers announce "collapsed"
CSS generated content announced (as "text element"):
#5
@
8 years ago
The button should be the full width of the clickable area for best consistency between the hover state and clickable region; definitely need to move the aria-expanded attribute to the correct element.
I think that a definition list is an appropriate semantic usage here. While some AT may misinterpret it, I think that's a problem with the AT, not with the element choice.
The current clickable button area is limited to the FAQ text.