quartz icon indicating copy to clipboard operation
quartz copied to clipboard

Accessibility

Open jasonday opened this issue 10 months ago • 4 comments

There are a bunch of accessibility issues.

I will start cataloguing them here and then open pull requests for fixes.

  • Use HTML5 landmarks to structure the page semantically - https://www.w3.org/WAI/ARIA/apg/patterns/landmarks/examples/HTML5.html
  • No "skip to main content"
  • Navigation "tree"
    • expandable top levels don't indicate expanded state, aria-expanded (don't update on toggle)
    • hidden navigation elements are accessible via keyboard when not visible (use display:none instead of grid-template-rows: 0fr)
  • On search
    • There's no indication that the user is put into a modal
      • This should be structured like a modal to ensure programmatic indication of such
    • User can't tab past the modal once open.
      • User has to know to use [esc]
      • User has to hit [esc] twice to close
      • There's no secondary method to close/cancel (close button)
    • There's no programmatic indication of results when typing in terms
    • Using [tab] from the search field takes the user to the second item in the list
    • On select of an item, the focus goes back to the search field - which is the behavior desired for closing modals, EXCEPT in this scenario where the user is navigating. The user's focus should be moved and behave similar to when navigating with a screen reader and selecting an item from the left navigation
    • It might make more sense to structure search as a combobox, and the results as options - https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/grid-combo/ or https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/
  • Multiple scrollbars is challenging for users (navigation, TOC)
  • The graph should probably have an aria-hidden="true" as it's unlikely to be able to meet WCAG 2.2 Guidelines
  • For list of tags, make it a <nav> element, and give it aria-label="tags"

jasonday avatar Mar 10 '25 19:03 jasonday

Is there any way for us to (programmatically) verify whether fixes for these are properly implemented?

saberzero1 avatar Mar 12 '25 02:03 saberzero1

@saberzero1 - yeah, I can add detailed info for some of these

jasonday avatar Mar 12 '25 12:03 jasonday

@saberzero1 - yeah, I can add detailed info for some of these

I meant more for automated testing as we no doubt will introduce more of these accessibility issues in the future as development continues.

saberzero1 avatar Mar 12 '25 12:03 saberzero1

There is automated testing (using tools such as Axe Core), and tests can be written for some specific things. I'll link some examples.

jasonday avatar Mar 12 '25 13:03 jasonday