search

department-of-veterans-affairs / vets-design-system-documentation

Repository for design.va.gov website
https://design.va.gov
60 stars 64 forks source link

508-defect-2 [COGNITION, KEYBOARD]: Focus MUST not be hidden by the leftnav #1104

Open joshkimux opened 2 years ago

joshkimux commented 2 years ago

508-defect-2

This is a duplicate ticket of the VAA issue here, but I assume it may be easier to fix at the source (hence the duplicate ticket here in DST).

Feedback framework

Definition of done

  1. Review and acknowledge feedback.
  2. Fix and/or document decisions made.
  3. Accessibility specialist will close ticket after reviewing documented decisions / validating fix.

Point of Contact

VFS Point of Contact: Josh

User Story or Problem Statement

As a keyboard user using magnification or on a smaller viewport, I always want to be able to see and track focus so I can navigate and interact with the page.

Details

At smaller viewports or when magnified, the in this section menu (leftnav) will become sticky on the page. This results in it occasionally covering focusable elements. Keyboard users who rely on visible focus to interact with the page will struggle to do so as shown in research done by the gov.uk team.

Keyboard users often navigate web pages using the TAB key to move through focusable elements, such as links and input boxes. The SHIFT + TAB key combination can be used to move through those elements backwards. We found that where the sticky header overlapped the page, navigating backwards through elements often left the focused element obscured by the sticky element.

This was an accessibility barrier for users. The sticky element was preventing a commonly used navigation technique from working properly, leaving users unable to see or read the element they had focused on.

Does this mean that sticky functionality should never be implemented? No, but it must be considered and tested carefully, particularly if the sticky element in any way overlaps other content. A safer use would be a sticky element positioned over an empty part of the page, or to have the content scroll in a way that it is never overlapped by the sticky element.

This is a sitewide issue that has been resolved before in ticket 19779 by referencing the in this section menu on Pittsburgh which is not sticky.

Acceptance Criteria

Environment

Steps to Recreate

  1. Enter https://staging.va.gov/careers-employment/vocational-rehabilitation/ in browser
  2. Reduce screen width to ~600px
  3. Tab all the way through the page
  4. Shift tab all the way back up the page
  5. Confirm focus is hidden by the sticky profile menu

Proposed Solution

This has been resolved before in ticket 19779 by referencing the in this section menu on Pittsburgh which is not sticky.

WCAG or Vendor Guidance (optional)

Screenshots or Trace Logs

Focus gets hidden when tabbing back up the page

https://user-images.githubusercontent.com/14154792/113886654-da62f280-978e-11eb-8226-60eadc7427a9.mov

https://user-images.githubusercontent.com/14154792/184384970-cf2ed2a4-b4a8-42b8-b534-159c3338ffea.mov

humancompanion-usds commented 2 years ago

@bkjohnson - Can you remind me - is the sidenav really in the Design System? It seems to be just a HTML and CSS example in Storybook.

@joshkimux - Depending on how Brooks responds, it may be that you'd need the CMS team to address this as I don't think sidenav is actually codified in the Design System yet and thus they would more likely be able to "fix it at the source". I would like to get the sidenav in as a component but, it is not a priority at the moment.

joshkimux commented 2 years ago

@humancompanion-usds I think there's currently documentation on the sidenav here in the design system where it's listed as a best practice

bkjohnson commented 2 years ago

The sidenav is sort of in the Design System in the sense that we have some CSS for it in formation, but even that isn't something that I would consider to be production quality. For example, it breaks on mobile. This might be why other teams have their own sidenav implementations.

SarahKay8 commented 1 year ago

Confirmed that menu is sticky at smaller viewport. Image 12-15-22 at 12.01 PM.jpg Is access to the menu at all times necessary, or could it just remain at the top and bottom of the pages? Is a sticky menu necessary, or could we consider shortening the amount of content on pages? I saw the comment that brooks left and he did mention "sidenav is apart of the design system because I know we have some css for it in formation". But he stated that wasn’t something he considered "production quality"@Andrew565 Could you take a look at this ticket and determine if DST is responsible for this update? Thanks in advance!

Andrew565 commented 1 year ago

We don't actually maintain the code for the sidenav even though we do have a storybook story covering how to use it. USWDS maintains the code for the sidenav component, so I think it's appropriate to kick this ticket to them. CC: @SarahKay8 @caw310

joshkimux commented 1 year ago

@jaredcunha is there any way we could write a ticket to USWDS to address this? @Andrew565 and team, given the severity of this issue, is this something we can document as a known accessibility problem in our documentation?

humancompanion-usds commented 1 year ago

@caw310 - This was closed but I don't see a resolution in this issue. Was this not a defect or was it addressed or...?

caw310 commented 1 year ago

@humancompanion-usds I don't think this was addressed. I'm going to reopen. I don't recall why we would have closed this.

rsmithadhoc commented 2 months ago

@caw310 @humancompanion-usds Since this issue was created, more problems with Sidenav have appeared.

image

USWDS also looks to have a different side navigation design. So I believe we either need to: bring this in line with USWDS as it is (a non-component, CSS-only thing), make it a proper web component with their design, or deprecate it.

humancompanion-usds commented 1 month ago

@rsmithadhoc - That's always been the case. It's because the sidenav styling doesn't work outside of the container within our typical page layouts for the sidenav. It was not coded as an independent component. We will fix this issue when we bring the sidenav into the Design System.