a11y improvements (Help Wanted!)

[endigo9740]

The aim is to improve overall accessibility across all component. This will be an on-going process that may be subdivided in to multiple parts.

ARIA reference

A11y Tooling

Highly recommend this video showcasing each of the following tools.

• axe DevTools
• Web Disability Simulator
• taba11y

Part 1 (components)

The following suggestions were provided by user "Tropical" on the Svelte Discord

Accordions

https://www.w3.org/WAI/ARIA/apg/patterns/accordion/

• [x] Convert to use <details> and <summary>
• [x] Support tab focus
• [x] Provide keyboard interaction
• [X] ARIA

NOTES:
- Animation not well supported with the <details> content region, so no animations for now
- Both slot ids have been updated to match the semantic names of their wrapping elements
- ARIA require unique ids, so we're generating these automatically, but can be overwritten on-demand

Buttons

https://www.w3.org/WAI/ARIA/apg/patterns/button/

• [x] Support tab focus
• [x] ARIA

NOTE: these updates are available to all components that embed a Button component

List

https://www.w3.org/WAI/ARIA/apg/patterns/listbox/

• [x] Support tab focus
• [x] Provide keyboard interaction
• [x] ARIA

NOTES:
- ListGroup/ListItem have been completely rebuilt to better support a11y
- NavItem component has been removed, replace with ListItem
- List docs are updated to reflect all changes

Menus

https://www.w3.org/WAI/ARIA/apg/patterns/menubutton/ https://www.w3.org/WAI/ARIA/apg/patterns/menu/

• [x] Support tab focus
• [X] Provide keyboard interaction
• [x] ARIA

NOTE: most Menu improvements are derived from the updates to the List/ListItem components

Radio Groups

https://www.w3.org/WAI/ARIA/apg/patterns/radiobutton/

• [x] Support tab focus
• [X] Provide keyboard interaction
• [x] ARIA

Slide Toggles

https://www.w3.org/WAI/ARIA/apg/patterns/switch/

• [x] Support tab focus
• [x] Provide keyboard interaction
• [x] ARIA

Tabs

https://www.w3.org/WAI/ARIA/apg/patterns/tabpanel/

• [x] Support tab focus
• [x] Provide keyboard interaction
• [x] ARIA

NOTE: users must provide their own 'tabpanel'.

[endigo9740]

Part 2 (components continued...)

Breadcrumbs

https://www.w3.org/WAI/ARIA/apg/patterns/breadcrumb/

• [x] Support tab focus
• [x] ARIA

Data Tables

https://www.w3.org/WAI/ARIA/apg/patterns/grid/

• [x] Support tab focus
• [x] Provide keyboard interaction
• [x] ARIA

Range Slider

https://www.w3.org/WAI/ARIA/apg/patterns/slider/

• [x] Support tab focus
• [x] Provide keyboard interaction
• [x] ARIA

Progress Bar / Radials

https://www.w3.org/WAI/ARIA/apg/patterns/meter/

• [x] Provide keyboard interaction
• [x] ARIA

Tooltips

https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/

• [x] Provide keyboard interaction
• [x] ARIA

[endigo9740]

Part 3 (misc)

Alerts

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/alert_role https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions

• [x] ARIA

Avatars

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figure

• [x] Parent wrapper should be <figure>
• [x] Support for alt text via $$props.alt

Badges

Only used for presentation

Cards

Only used for presentation

Dividers

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/separator_role

<hr> tags have an inherit role of role="separator"

Gradient Headings

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/heading_role

H1-6 headings have inherit role, but since any tag can be provided I've added role="heading" just in case.

Logo Clouds

Only used for presentation

Paginator

• [x] Updated parent tag from <div> to <nav>

Steppers

It's similar to an accordion, but operates differently. We may need outside feedback on this.

[endigo9740]

Part 4 (utilities)

Code Blocks

https://whitep4nth3r.com/blog/how-to-make-your-code-blocks-accessible-on-your-website/

• [x] Background color is now a static dark gray (nearly black) for improved contrast
• [x] Code now wraps instead of overflow scroll (for keyboard-only users)

Light Switch

https://www.w3.org/WAI/ARIA/apg/patterns/menubutton/ https://www.w3.org/WAI/ARIA/apg/patterns/menu/

• [x] Support tab focus
• [x] Provide keyboard interaction
• [x] ARIA

NOTE: LightSwitch has been redesigned per: https://github.com/Brain-Bones/skeleton/issues/78#issuecomment-1218611725

Changes:
- New slide toggle visual style
- Much compact, no menu component
- Still uses the OS preference on first time visit
- Persists light/dark after user selection
- Uses context:module to share state if multiple are visible (try on docs)
- New local storage value of "mode" (was "theme")

Dialogs

https://www.w3.org/WAI/ARIA/apg/patterns/dialogmodal/

• [x] Support focus trapping
• [x] ARIA

NOTE: we should create a ticket to migrate this to a native <dialog> element

Toasts

https://www.w3.org/WAI/ARIA/apg/patterns/alert/

• [x] ARIA role of "alert"

Filters

For presentation only. We may want to have color/contrast warnings though.

[endigo9740]

Part 5 (tests)

NOTE: all tests are now passing. We may want to evaluate each test in detail later. But for now this should suffice.

[endigo9740]

Hey everyone! So great news regarding accessibility (a11y) updates. I've now completed the first round of updates improving a11y for ALL (yes all) components and utilities within Skeleton. The biggest areas of improvement include tab focus, keyboard interactions, and properly defined ARIA attributes.

This is a rather large and impactful update that touches a little bit of everything in the entire library. Just take a look at the commit history here:

https://github.com/Brain-Bones/skeleton/commits/feat/a11y

However, it does come with a few notable and/or breaking changes:

• The Accordian no longer animates due to <details> and <summary> not yet properly supporting this natively. However, my hope is this can return in the future. BUT, a11y comes first!
• The List and it's children components have been rewritten from scratch. Plus the NavItem features have been merged into ListItem, so NavItem goes away
• Dialogs now utilize proper focus control, such as being able to tab between a prompt input and the cancel/confirm actions.

Given the broad amount of changes, I am calling for your help with testing!

And no, you do NOT have to be an a11y expert to test these updates. Literally anyone that can pull down the branch can test. Mainly, I need help with regression testing. With minor updates in so many places, we need to ensure nothing has broken inadvertently. Just pull down the branch and start browsing the Doc site locally. Test everything you can between each component. Maybe create your own page to test different settings per the components with the most changes.

Long story short, if you're availble to help test, please let me know here, pull down the branch, and keep me posted as you progress. You can report all issues to the ticket above. The sooner testing concludes, the sooner we can get this update out to everyone! And the sooner I can move onto critical issues such as decoupling Skeleton from SvelteKit, new features and updates, etc.

The three attached screenshots demonstrate:

• Tab focus on the homepage, which utilizes a variety of different Skeleton components
• Colorblind support - though color/contrast/vision testing still needs a lot more work
• The axe Dev Tools accessibility score. Again highlighting our biggest gap remaining is vision-based issues

[endigo9740]

For anyone interested in testing, here's the steps required:

1. Clone a version of Skeleton to your local device: git clone https://github.com/Brain-Bones/skeleton.git
2. Checkout the a11y code branch: git checkout feat/a11y
3. Move into the project directly: cd skeleton
4. Install NPM dependencies: npm install
5. Run a local dev server: npm run dev and point your browser to: http://localhost:3000/

Now that you have the project running locally, try and test the following:

• Navigate through the entire local site testing each and every component.
• Ensure there's no console log errors.
• Ensure the component examples work as you would expect
• Ensure the documented props match what's shown in the examples above
• Review the newly add Accessibility section at the bottom of each component doc page. Verify the ARIA link and all props match expectations
• (OPTIONAL) if you're feeling adventurous, create a new blank route page and start importing and testing each component with different props and settings. Especially ARIA attribute props.
• (OPTIONAL) if you wish to test the a11y of each component, see the list of Chrome extensions at the top of the original post. These are pretty easy to use, but I'll provide a link to a great video intro below:

https://www.youtube.com/watch?v=IaJtAzaFiJ4

Finally, it will be critical to test components with the largest amount of changes. These include:

• The List/ListItem components - which have been completely rewritten from the ground up! Note that NavItem is no longer present, this was merged into ListItem.
• The Accordion - it now uses <detail> and <summary> tags for more native expansion groups. (MDN page)
• Dialogs - these now attempt to capture and retain focus per the ARIA guidelines linked at the bottom of the docs page.
• For all other changes, see the notes included in the first handful of posts on this ticket!

If you find issues please report them here. Thanks for your help!

[niktek]

Nice work on this so far :)

So doing a side by side comparison between master and feat-a11y and doing a scan with the axe extension for now:

There are two overall ARIA reported issues of colour and heading levels and some minor ones on specific pages.

But this comment focuses on actual Skeleton regressions found in RadioGroup and Slide Toggle no longer working and hence any dynamic preview of other components that use these two components on their docs page also don't work.

http://localhost:3000/components/avatars - Buttons and Slide Toggles no longer working http://localhost:3000/components/buttons - Slide Toggle for Disabled no longer working http://localhost:3000/components/data-tables - there are new aria props, but they aren't used in the example and it doesn't get picked up by the axe report. http://localhost:3000/components/dividers - we have lost functionality to modify the divider http://localhost:3000/components/progress-bars - Determinate and Height buttons are broken http://localhost:3000/components/radio-groups - both justify and horz/vert sample don't click http://localhost:3000/components/slide-toggles - all slide toggles broken

[endigo9740]

Awesome Nik, thanks. Really strange issues, but this is why we test! I'll take a look!

[endigo9740]

Ok, so these were pretty straight forward regressions due to these two components:

• Range Slider: I recently swapped the parent element from a <label> to a <div> to address an axe warning. But this was needed since the label click event natively toggles the input element within. I've now introduced the label one level deeper, which keeps this functional while also keeping axe happy
• Slide Toggle: same deal, adjusted the <label> position to remove the issue

Per Data Tables (and really most components), the ARIA attributes require unique values (like unique ID), so we provide pass through value using props. The convention is aria-label is set by label for example. We could auto-generate default IDs, but I feel that goes against the whole point. That being, descriptive information for people using screen readers, etc. For example, "table-99" won't be very helpful!

Great catches though, hopefully these these were our biggest offenders!

[endigo9740]

These changes have been merged into the dev branch but still open to additional testing before release.

[endigo9740]

Reopening this until @thomasbjespersen can finish QA on it.

[thomasbjespersen]

Taking this on @endigo9740.

[endigo9740]

FYI i'm closing this for now. Please keep me posted if you have any issues related to these changes @thomasbjespersen