![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 4 weeks ago
Last modified 3 weeks ago
#8305 new defect (bug)
Plugin screenshot lightbox has nested controls
| Reported by: | joedolson | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Plugin Directory | Keywords: | accessibility |
| Cc: |
Description
The plugin screenshot lightbox trigger has an a element wrapped around the image and the lightbox button. This creates several accessibility issues:
1) Extremely unpredictable behavior: in rare cases, nested controls can create circulate keyboard interaction, e.g. tab cycles between the outer element and the inner element. While uncommon, it's disastrous when it occurs.
2) Extra tab stops. It takes twice as long to navigate through images, because every lightbox control has two tab stops.
3) Confusing controls: there are two controls, one a link with name '[image alt] Enlarge 2 of 8' and one a button with the name 'Enlarge 2 of 8'. (The anchor inherits the name from both controls within it). A link is expected to link to a separate location, so it sounds like this will possibly be a link to the named image; the button sounds like it will possibly open a modal. They actually do the same thing.
4) But...actually they don't. The link doesn't have any keyboard event handlers, so it doesn't do anything.
The reason for having the wrapping a element is presumably to make the entire image surface clickable, and that's not unreasonable - it's a functionality that exists in many other contexts around .org. However, this is not a good way to implement it.
Because there's already a control that handles the triggering, it's not necessary to use a control element for the additional click trigger; it can be assigned directly to the image element. The button will handle keyboard usage needs.
Change History (3)
#2
follow-up:
↓ 3
@
3 weeks ago
For a no-JS fallback, the logical thing is probably to remove the wrapping a element using JS, so that it's only present if JS fails.
#3
in reply to: ↑ 2
@
3 weeks ago
Replying to joedolson:
For a no-JS fallback, the logical thing is probably to remove the wrapping
aelement using JS, so that it's only present if JS fails.
Yes, that looks like the right direction. I will take this on and try to keep the fallback cleanly without the extra nested control
Thanks, this looks like a valid follow up 🙂 This is where two goals collided, keeping the whole image surface clickable and keeping a no-JS fallback. I added that wrapper around the image for exactly that reason, so the report is fair.
I will take another pass and see if I can keep the fallback without the extra nested control and extra tab stop.