Accessibility tab issue on 526 pages

[pacerwow]

Issue Description

As a Veteran I want to navigate through the 526 form without a mouse so that I can submit an application even if I am not able to use a computer mouse.

When tabbing through the 526 form, we noticed that the tab button skips some of the radio buttons on a couple of pages. Noticed this for adaptive-benefits additional-disability-benefits

There may be more, will need to go back and look more thoroughly.

---

Tasks

• [ ] Fix the known issues on the above two pages
• [ ] Write a test case as needed that covers navigating the form without a mouse ^only in scope for this ticket

Break this out (Jared to do) - these are not in scope

• [ ] Review all form 526 pages to ensure this functionality is present for every interactive form element
• [ ] For any identified issues, create one Github ticket to address those issues

Acceptance Criteria

• [ ] Given a Veteran is using a keyboard to navigate through the form
• [ ] And they use the tab button or similar interaction method to 'tab' through interactive form elements
• [ ] Then the Veteran should be able to select any form element they want without using a mouse

---

How to configure this issue

• [ ] Attached to a Milestone (when will this be completed?)
• [ ] Attached to an Epic (what body of work is this a part of?)
• [ ] Labeled with Team (product support, analytics-insights, operations, service-design, Console-Services, tools-fe)
• [ ] Labeled with Practice Area (backend, frontend, devops, design, research, product, ia, qa, analytics, contact center, research, accessibility, content)
• [ ] Labeled with Type (bug, request, discovery, documentation, etc.)

[bacitracin]

Hey there! Here's my repro results: I tested these 2 pages on staging with Chrome and Safari and could not recreate the bug of skipping radio buttons. I went over it with Tyler Spangler to make sure I wasn’t missing any hidden bits of the form.

Here is the expected behavior of the radio group, which I confirmed:

• When tabbing to the radio group (forwards with TAB or backwards with SHIFT + TAB), if an option is already selected, focus lands on the selected item.
• If nothing is selected in the radio group yet, tabbing will move focus to the nearest option (tabbing forwards it will pick the first, backwards it picks the last), but does not select it.
• You can then select an option by pressing SPACE or by using the UP/DOWN or LEFT/RIGHT arrows.
• If you TAB again while focused on a radio button, you will be taken out of the radio group to the next focusable element.

Both pages’ radio button groups are using the Yes-no widget from the VA forms library, so I’m pretty confident that it should be good. Here’s some additional documentation on expected behavior of the radio group pattern - https://www.w3.org/WAI/ARIA/apg/patterns/radio/.

If you have more repro directions, please let me know and I'll test it again. Otherwise if the behavior seems as described we can close this issue.

[pacerwow]

Thanks Tracy! Appreciate the thorough notes. I think the language I should have used was "move focus", not select. Would you mind taking 10 minutes to do a quick test using Edge to just make sure it's not reproducible there? If it's not, we can close the story.

Do you feel that a test case here is a good idea? If it's not, we can close the story.

[bacitracin]

@pacerwow Will do! I'll throw in Firefox too so we're covered on the browsers we support. I don't think a test case is necessary at the moment. If I don't find anything 🤞 , I'll close this issue.

[bacitracin]

Checked across 4 browsers and was not able to reproduce the bug. Closing this issue for now.

[pacerwow]

Sounds great, thanks!-JaredOn Aug 30, 2024, at 10:13 AM, Tracy Tran @.***> wrote: Checked across 4 browsers and was not able to reproduce the bug. Closing this issue for now.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>