'Report an issue with dark mode' button not keyboard-focusable
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	TheresNoTime
	Jul 30 2024, 1:01 PM

Project Tags

Referenced Files

	F57245104: screenshot 2.png
	Aug 10 2024, 5:49 PM

	F57245093: screenshot.mov.gif
	Aug 10 2024, 5:49 PM

	F56923410: 2024-08-02_07-24-03.mp4.gif
	Aug 2 2024, 2:25 PM

	F56878763: 2024-08-01_08-04-17.mp4.gif
	Aug 1 2024, 3:06 PM

	F56878759: 2024-08-01_08-01-30.png
	Aug 1 2024, 3:03 PM

	F56840795: 2024-07-31_15-50-41.mp4.gif
	Jul 31 2024, 10:54 PM

	Restricted File
	Jul 30 2024, 1:51 PM

	F56787038: image.png
	Jul 30 2024, 1:01 PM

Subscribers

Description

"Report an issue with dark mode" link/control - which is implemented as an <a> element without href, so it's not keyboard-focusable. also, it acts as a button rather than being a link, and just transforms into a static bit of text once you click it with the mouse, so they'd also need to handle focus there after activation

(Reporting on behalf of Patrick H. Lauke on Mastodon)

Requirement

Ensure that the "Report an issue with dark mode" button is keyboard-focusable and behaves like a button, retaining focus after activation.

BDD

Feature: Improve Accessibility of the "Report an issue with dark mode" Button

  Scenario: Keyboard accessibility for the "Report an issue with dark mode" button
    Given the user is navigating with a keyboard
    When the user tabs to the "Report an issue with dark mode" button
    Then the button should be focusable

  Scenario: Focus management after activation
    Given the user clicks the "Report an issue with dark mode" button
    When the button transforms into static text
    Then the focus should be retained on the static text

Test Steps

Test Case 1: Verify Keyboard Accessibility for the "Report an issue with dark mode" Button

Navigate to the page with the "Report an issue with dark mode" button.
Use the keyboard to tab through the interactive elements.
AC1: Confirm that the "Report an issue with dark mode" button is keyboard-focusable.

Test Case 2: Verify Focus Management After Button Activation

Use the keyboard or mouse to activate the "Report an issue with dark mode" button.
AC2: Confirm that focus is retained on the static text after the button is clicked.

QA Results - Beta

AC	Status	Details
1	✅	T371377#10034037

QA Results - Prod

AC	Status	Details
1	✅	T371377#10055758
2	✅	T371377#10055758

Details

Related Changes in Gerrit:

	Subject	Repo	Branch	Lines +/-
	Make fake link a button	mediawiki/skins/Vector	master	+3 -0

Customize query in gerrit

Related Objects

Mentioned In: T371113: Verify 1.43.0-wmf.17 deployment
Mentioned Here: T370825: Remote, unmoderated user testing for logged out link reporting system
T370233: [Spike 2 days] Work out how to automate reported user feedback
T371325: Issue with logging for "report issue" for logged out users

Event Timeline

TheresNoTime created this task.Jul 30 2024, 1:01 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 30 2024, 1:01 PM

TheDJ merged a task: T371381: Report an issue in Appearance menu should use role=button.Jul 30 2024, 1:25 PM

TheDJ subscribed.

currently, the markup for this is just <a>Report an issue...</a>. Anchor elements without an href attribute are not keyboard focusable.

*When not logged in*, the control acts as a button to trigger an action (rather than navigating somewhere, which is what links are for), it should be coded as a <button> element (and styled accordingly to make it look the same as now, if you want). Make sure to have a focus indicator/outline when it receives keyboard focus too.

Once activated, the control turns into static text that just confirms the submission. This should be made explicitly focusable using tabindex="0" and focus moved to it programmatically using .focus() method (otherwise, focus will be lost/reset to the start of the page for screen reader users).

*When logged in* (which I only just discovered), the control actually does open a new page and acts as a link and opens "https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading/Reporting/..." in a new tab. I'd say even in this case though, it makes sense to initially expose the control as a <button>.

If it's not possible to use actual <button> markup, you can keep it an <a> element, but make it explicitly keyboard-focusable and give it a role of button - <a tabindex="0" role="button">Report an issue...</a>

Incidentally, when the appearance panel is hidden and turned into a dropdown, the fact that the control is not focusable becomes even more obvious and annoying, as a user will tab through the radio buttons, expecting to reach the "Report..." control, and instead they jump out of the dropdown.

{F56788174}

@Jdlrobson I was looking at this, and there is more going on here that i do not understand...

// per requirements: only logged in users can report errors

And then for users its adds an href and a target attribute... but it DOES add the element itself and a 'success' handler for anon users...
This seems strange... are we just pretending that anon users can provide feedback ? Or are we accidentally adding that element when we shouldnt be ?

This seems strange... are we just pretending that anon users can provide feedback ? Or are we accidentally adding that element when we shouldnt be ?

We were supposed to be logging events on every click, and then the idea was to provide summaries of that data to the community.
However, as we started working on generating these reports in T370233 we discovered a bug (T371325) which meant this isn't working so we're currently in the process of re-evaluation (T370825).
We want anons to provide feedback but there are concerns (not mine) that if we push them to the talk page, we'll get a lot of spam/useless reports from IP users.

In T371377#10029926, @Jdlrobson wrote:

This seems strange... are we just pretending that anon users can provide feedback ? Or are we accidentally adding that element when we shouldnt be ?

We were supposed to be logging events on every click, and then the idea was to provide summaries of that data to the community.
However, as we started working on generating these reports in T370233 we discovered a bug (T371325) which meant this isn't working so we're currently in the process of re-evaluation (T370825).
We want anons to provide feedback but there are concerns (not mine) that if we push them to the talk page, we'll get a lot of spam/useless reports from IP users.

right.. so for now it doesn't do anything for anons other than show a notification and that is expected.

Change #1058253 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/skins/Vector@master] Make fake link a button

https://gerrit.wikimedia.org/r/1058253

gerritbot added a project: Patch-For-Review.Jul 30 2024, 9:07 PM

Jdlrobson assigned this task to Edtadros.Jul 31 2024, 3:39 PM

Jdlrobson triaged this task as Medium priority.

Jdlrobson edited projects, added: Unplanned-Sprint-Work, Web-Team-Backlog-Archived (FY2024-25 Q1 Sprint 3); removed: Web-Team-Backlog-Archived.

Jdlrobson moved this task from Needs analysis to QA on the Web-Team-Backlog-Archived (FY2024-25 Q1 Sprint 3) board.

Change #1058253 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Make fake link a button

https://gerrit.wikimedia.org/r/1058253

Maintenance_bot removed a project: Patch-For-Review.Jul 31 2024, 4:33 PM

ReleaseTaggerBot added a project: MW-1.43-notes (1.43.0-wmf.17; 2024-08-06).Jul 31 2024, 5:00 PM

@Jdlrobson Can you please validate the gif, if this is what you want for keyboard focus? It shows I can navigate into the section by pressing the tab button. While in the color section, I can navigate by using the up/down arrows. To get to 'report an issue with dark mode', I have to push the tab button. When I click the Enter button, it goes to the Editing Reading/Web/Accessibility for reading/Reporting/en.wikipedia.beta.wmflabs.org (new section) page (ex. https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading/Reporting/en.wikipedia.beta.wmflabs.org?section=new&action=submit&preloadtitle=[https://en.wikipedia.beta.wmflabs.org/wiki/Robert_Mambo_Mumba%20Robert%20Mambo%20Mumba]%20dark%20mode%20error&preload=MediaWiki:vector-night-mode-issue-reporting-preload-content)

Test Result - Beta

Status: ✅ PASS
Environment: Beta
OS: macOS Sonoma 14.5
Browser: Chrome 127
Device: MBA
Emulated Device: NA

Test Step(s):

Visit any page (ex. https://en.wikipedia.beta.wmflabs.org/wiki/Robert_Mambo_Mumba#cite_note-3)
Make sure you can keyboard tab/arrow in and out of the section and choose the color, along with reporting an issue going to the correct page.

Keyboard Focus

2024-08-01_08-04-17.mp4.gif (1,418×930 px, 1 MB)

Keyboard Focus w/o Sidebar

href "Report an issue with dark mode"

GMikesell-WMF removed Edtadros as the assignee of this task.Jul 31 2024, 10:54 PM

GMikesell-WMF updated the task description. (Show Details)

GMikesell-WMF moved this task from QA to Ready for Signoff on the Web-Team-Backlog-Archived (FY2024-25 Q1 Sprint 3) board.

GMikesell-WMF added a subscriber: Edtadros.

Izno added a project: Vector 2022.Aug 1 2024, 12:12 AM

Jdlrobson assigned this task to ovasileva.Aug 1 2024, 4:17 PM

NBaca-WMF reassigned this task from ovasileva to bwang.Aug 1 2024, 4:46 PM

NBaca-WMF added a subscriber: ovasileva.

Edtadros mentioned this in T371113: Verify 1.43.0-wmf.17 deployment.Aug 8 2024, 8:27 PM

Test Result - Prod

Status: ✅ PASS
Environment: enwiki
OS: macOS Sonoma
Browser: Chrome
Device: MBA
Emulated Device: NA

Test Artifact(s):

Test Steps

Test Case 1: Verify Keyboard Accessibility for the "Report an issue with dark mode" Button

Navigate to the page with the "Report an issue with dark mode" button.
Use the keyboard to tab through the interactive elements.
✅AC1: Confirm that the "Report an issue with dark mode" button is keyboard-focusable.

Test Case 2: Verify Focus Management After Button Activation

Use the keyboard or mouse to activate the "Report an issue with dark mode" button.
✅AC2: Confirm that focus is retained on the static text after the button is clicked.