Opened 8 weeks ago
Closed 4 weeks ago
#62093 closed defect (bug) (fixed)
Post format radio buttons labels not working with screen readers interaction modes
Reported by: | talksina | Owned by: | |
---|---|---|---|
Milestone: | 6.7 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Editor | Keywords: | needs-testing |
Focuses: | accessibility | Cc: |
Description (last modified by )
When writing a post and changing post format, radio buttons to choose different formats (audio, status, standard, etc) are labeled but labels are not readable correctly by screen readers when in forms or interaction mode.
Currently tried with JAWS for Windows 2024 latest build and NVDA 2024.3.
STEPS to reproduce:
- add a new post or edit an existing one
- tab until focus goes to "change post format" button. Expand it.
- tab to the first radio button, it will read "radio button selected" without saying what it is.
- To test it completely, turn virtual cursor off (jawskey+z) or focus mode on (nvda key + space) on NVDA.
- Pressing up and down arrows to change radio button, it will select options without reading what they are.
- It works instead, when virtual cursor is active and the windows is being consulted like a page, with arrows as it were a Word document, and selecting a single radio button with spacebar.
I suspect the issue is on a possibly inconsistent semantic HTML association.
div class="components-radio-control__option" input id="post-format-selector-0" class="components-radio-control__input" type="radio" name="inspector-radio-control-0" value="status"
label class="components-radio-control__label" for="inspector-radio-control-0-4" Stato /label /div
seems that label is associated to the "name" attribute instead of the "id" and this might create the conflict.
Please check
Change History (13)
#1
@
8 weeks ago
- Component changed from Post Formats to Editor
- Description modified (diff)
- Focuses coding-standards removed
#3
@
8 weeks ago
- Keywords close added
You're right - I confirm that labelling has been solved (I switched to 19.2.0 of Gutenberg plugin to test it)
I had to revert to stable gutenberg version after 19.2 release, because of issue GB65267 I reported on github that's why I noticed the labelling bug.
#4
@
6 weeks ago
- Keywords close removed
- Milestone changed from Awaiting Review to 6.6.3
Thanks for retesting and confirming @talksina.
I too think it was solved by https://github.com/WordPress/gutenberg/pull/64582, which shipped in GB 19.1.
Hey @mciampini and @vcanales, does https://github.com/WordPress/gutenberg/pull/64582 resolve this reported issue? If yes, though it's marked as an enhancement, could it be considered a bugfix or even regression?
Milestoned this ticket for 6.6.3, as introduced in the 6.6.x cycle.
#5
@
6 weeks ago
seems that label is associated to the "name" attribute instead of the "id" and this might create the conflict.
This assessment by @talksina is correct; I would consider this a bug.
The fix has also been in Gutenberg for a few releases now, and with that exposure, I think it is safe to backport. I've labelled it for that.
#6
follow-up:
↓ 7
@
6 weeks ago
Agreed with @vcanales , that PR could be considered a bug fix (not a regression, since AFAIK the previous behaviour had been around for a while / since the inception of the component).
#7
in reply to:
↑ 6
@
5 weeks ago
Replying to mciampini:
PR could be considered a bug fix (not a regression, since AFAIK the previous behaviour had been around for a while / since the inception of the component).
Is the bug reported in this Trac ticket part of this "previous behaviour"? Was that previous behaviour introduced in the 6.6 cycle?
@vcanales @mciampini
#8
@
5 weeks ago
From what I understand, it was part of the previous behaviour. And, to my knowledge, that's how the component behaved for a long time — so, not a regression introduced in 6.6.
#9
@
5 weeks ago
- Milestone changed from 6.6.3 to 6.7
- Version 6.6.2 deleted
Clearing out the Version and moving to 6.7 based on reporter feedback from @mciampini
#10
@
5 weeks ago
I’ve tested this issue and confirmed that screen readers are reading the labels correctly in interaction mode.
#11
@
5 weeks ago
QA Update: ✅
I have tested using iOS Voice over and confirmed that the screen reader are reading the labels correctly
Testing Environment
- WordPress: 6.7-beta2
- Theme: TT5 1.0
- PHP: 8.0.30
- Web Server: Nginx 1.20.2
- Browser: Chrome
- OS: macOS Ventura 13.3
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
4 weeks ago
#13
@
4 weeks ago
- Resolution set to fixed
- Status changed from new to closed
As far as I can tell, this issue is resolved upstream with the merge to Gutenberg, and is already in the 6.7 editor tasks board as done. Since it will not be backported to a potential future 6.6.3 release, I'm going to go ahead and close this issue.
Hi and thanks for the report!
I can confirm that the Post Format labeling has a problem in WordPress 6.6.2. The Gutenberg plugin seems to have fixed that between versions 18.8.0 and 19.2.0, possibly involving GB64582.
I would like someone else to test it before closing the ticket. If you do not have the Format option in the post settings, you could switch your theme to Twenty Twenty-One.