a11y improvements (Help Wanted!) about skeleton HOT 13 CLOSED

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

from skeleton.

Taking this on @endigo9740.

from skeleton.

Part 2 (components continued...)

Breadcrumbs

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

• Support tab focus
• ARIA

Data Tables

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

• Support tab focus
• Provide keyboard interaction
• ARIA

Range Slider

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

• Support tab focus
• Provide keyboard interaction
• ARIA

Progress Bar / Radials

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

• Provide keyboard interaction
• ARIA

Tooltips

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

• Provide keyboard interaction
• ARIA

from skeleton.

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

• ARIA

Avatars

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

• Parent wrapper should be <figure>
• 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

• Updated parent tag from <div> to <nav>

Steppers

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

from skeleton.

Part 4 (utilities)

Code Blocks

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

• Background color is now a static dark gray (nearly black) for improved contrast
• 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/

• Support tab focus
• Provide keyboard interaction
• ARIA

NOTE: LightSwitch has been redesigned per: #78 (comment)

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/

• Support focus trapping
• 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/

• ARIA role of "alert"

Filters

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

from skeleton.

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.

from skeleton.

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

from skeleton.

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!

from skeleton.

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

from skeleton.

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!

from skeleton.

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

from skeleton.

Reopening this until @thomasbjespersen can finish QA on it.

from skeleton.

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

from skeleton.