Opened 7 years ago

Closed 7 years ago

#2670 closed defect (bug) (maybelater)

Plugin Theme: FAQ toggles only on button click

Reported by: alpipego's profile alpipego Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords: has-screenshots ux-feedback a11y-feedback


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)

faq-button.jpg (13.1 KB) - added by kevinwhoffman 7 years ago.
The current clickable button area is limited to the FAQ text.

Download all attachments as: .zip

Change History (9)

7 years ago

The current clickable button area is limited to the FAQ text.

#1 @kevinwhoffman
7 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.

7 years ago

#3 @afercia
7 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:

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.


The question is expanded but aria-expanded is still false, thus screen readers announce "collapsed"

CSS generated content announced (as "text element"):

#4 @rianrietveld
7 years ago

  • Keywords a11y-feedback added

#5 @joedolson
7 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.

#6 @SergeyBiryukov
7 years ago

The main issue appears to be fixed in [5244], but comment:3 should be addressed as well.

#7 @Ipstenu
7 years ago

  • Summary changed from FAQ toggles only on button click to Plugin Theme: FAQ toggles only on button click

#8 @tellyworth
7 years ago

  • Resolution set to maybelater
  • Status changed from new to closed

Remaining issue deserves its own ticket.

Note: See TracTickets for help on using tickets.