New Patterns section: React/Angular/Vue Components

[svinkle]

I think the next evolution of the Patterns page is to include accessible React/Angular/Vue components.

There's been some amazing work happening with React components as of late. A few that I've been watching come to mind:

• https://github.com/paypal/downshift by @kentcdodds & contributors
• https://github.com/atlassian/react-beautiful-dnd by @alexreardon & contributors

While these aren't exactly 💯 accessible (planning on sending some PRs) I think they're worth including.

Be on the lookout for any accessible React/Angular/Vue components to contribute to this new section! 😄

[alexreardon]

react-beautiful-dnd does a fair bit to be accessible, but could do more. Feedback, assistance and pull requests are welcome!

[svinkle]

@alexreardon thanks for commenting! It totally does do a fair bit, I agree. I checked it out and it has really great keyboard support!

One main issue I found right away was a lack of announcements and/or instructions when using it with a screen reader. Audible cues like:

• How to pick up and put down items
• Which order items are now in after dropping
• How many items there are in total
• Semantic meaning for each item (currently announced as, "link")

These types of messages are essential in order for people who rely on assistive tech such as a screen reader to be successful in using a tool such as react-beautiful-dnd.

I'd like to dig in and help out with this for sure, time permitting. 🙂

[alexreardon]

We already have an issue to work on this: https://github.com/atlassian/react-beautiful-dnd/issues/7

👍

[joe-watkins]

@svinkle I'm wondering if we should segment patterns by libraries/frameworks? (We know how they come and go.)

Maybe some sort of tagging/badging system along with continued sorting by pattern could work.

e.g.

Auto-complete

• Downshift [react]
• Typeahead [angularjs]
• Some other [vanillajs]

[svinkle]

@joe-watkins Fine idea! I had the same thought way back about tagging patterns built with jQuery/vanilla JS, CSS/SASS, etc. We could add some sweet SVGs to make it look awesome, too. 🙂

[svinkle]

Components to add by @davidtheclark:

• react-aria-modal • react-aria-menubutton • react-aria-tabpanel

[alexcarpenter]

A few react components by Hugo Giraudel:

• react-a11y-dialog
• react-menu-button

[kentcdodds]

Also, a few days ago I created react-toggled 😀

[svinkle]

Will be including GoogleChrome/howto-components, via @robdodson.

[marcus-herrmann]

One could point to https://docs.angularjs.org/api/ngAria, which is part of Angular, thanks to @marcysutton

[marcysutton]

This is more framework-agnostic (though it does use jQuery), but the best accessible drag & drop solution I've seen is https://github.com/schne324/dragon-drop

[svinkle]

@marcysutton Totally agree; the usability and amount of audible feedback with dragon-drop is really awesome. @schne324 did a fantastic job. 👍

[tvooo]

Skyscanner's design system Backpack features lots of accessible React components: https://github.com/Skyscanner/backpack/

I was also impressed by the Microsoft Office UI Fabric date picker: http://dev.office.com/fabric#/components/datepicker

[svinkle]

Totally need to include react-theme-switch by @Heydon. 👍

[svinkle]

A couple aria-live region components:

• react-a11y-announcer
• vue-a11y-announcer

[Heydon]

Totally need to include react-theme-switch by @Heydon. 👍

Be my guest! Thank you.

[schne324]

@svinkle I wrote a framework-agnostic live region module: https://www.npmjs.com/package/live-region. It is pretty simple so it could easily plugin to frameworks like react and vue

[stowball]

I wrote react-accessible-tabs a year ago

[resource11]

What about react-a11y-patterns by @AlmeroSteyn?

[webuxr]

@svinkle Seems like this issue about “React/Angular/Vue” befriended Angular and Vue. ;)

I think @joe-watkins was on the correct path with further segmenting our Patterns page to include library/framework/etc.

I’d like to add a few notes about this:

1. Adding A11y patterns that are specific to front-end libraries, frameworks, CMS solutions, or templating systems could mean going deep into implementation-level details. Honestly, this screams scope creep for the core purpose of the A11yproject.
2. Regardless of the framework tool being used, the a11yproject.com site seems better suited for illustrating how to correctly implement HTML so it’s valid, compliant, and accessible; not showing how “react-xyz” compiles as “aria-xyz”.
3. Diving into library/framework waters dilutes the KISS principle.
4. There’s nothing wrong with listing library/framework options as a new segment on the Patterns page. OTOH, I think it would be much more useful to present such an ever-growing list of 2 groups (sub-segments?): those that produce solid, accessible HTML, and those that produce solid HTML but need extra work to make them accessible.
5. In ref to the above, perhaps a third sub-segment would be library/framework options that are in-between these 2 sub-segments where they do some accessibility well and here’s a list of the “gotchas”.

Please keep in mind this only my opinion. I don’t mean to be a buzzkill here and squash anyone’s enthusiasm—this is all good stuff. I just want to be mindful of still open issues that could really benefit the users of the A11y site. Open issues like #12 which is now over 5 years old.

My apologies if I’m off-base here. Thoughts?

Cc: @davatron5000

EDIT: Fixed typos and mis-mention.

[davetron5000]

Did you mean davatron5000?

if not…how can I help :)

[svinkle]

@webuxr All valid thoughts. This thread is still up in the air of what exactly the plan is on presenting the findings here. Will it be a section, sub-section, or a brand new page? Not sure.

Before we make any final decision on how to present, the initial plan was to ensure usability and accessibility standards before official recommendation. As we've seen in the past, sometimes a component will claim being accessible when in reality, a quick look through the generated source or testing with a screen reader will say otherwise.

I saw this more of an opportunity for folks to gather components, and for anyone willing, to try them out and test for accessibility issues. If the component was not quite up to par, we'd be able to go in and help the project maintainer by sending some friendly PRs to ensure accessibility (as much as possible.) In other words, it would be an opportunity for folks to learn, share some knowledge, and connect with others at the same time. The whole "social coding" bit. 😉

As far as this being out of a11yProject scope? Maybe. Again, it's all still up in the air. I wanted to provide a resource for folks who are working with these frameworks/libs a singular "source-of-truth" for when it came time to grabbing an "accessible" component. I was thinking it would also be a sort of "a11y win" for the component maintainer to have their work appear on the site as a recommended accessible component.

As far as stale issues, I've implemented a set of guidelines to handle stale/old issues. I left #12 open as it featured a fantastic to-do list of sorts where we can point people to who are looking to contribute something to the project.

So, with all this said, I probably should have something stating the purpose of this particular thread. And that purpose being:

• Create a collection of components which claim to be accessible.
• Go to each component and test validity of said claim.
• If a11y is good, great! Accept as "a11yProject approved" recommended component.
• If a11y is not so good, that's ok! We can help out by sending PRs to the repo.
• Present recommended components on the site… still to be determined.

Thoughts?

[davatron5000]

👋 Howdy. Chiming in. Hopefully its helpful.

I think I'd personally love some dependency badging system on the Patterns page. We already have quite a few (jQuery) ones. Maybe something like Labels in GitHub Issues.

It seems like there's value/demand in providing React/Angular components as well, the key difference being that these tend to be pre-packaged solutions. Just like the difference between a "Hamburger Menu" pattern demo and the whole jPanelMenu jQuery plugin. npm install and assume its taken care of.

A lot of developers want the solution before they know what the problem is. That's maybe not the most ideal situation, but a lot of things (like Tabs) should be solved problems.

IMHO, I think we should err on the side of keeping Patterns as demo'ing the concept as simple as possible. Keep it educational.

But I think there is value in helping developers who just need to "get 'r dun" and want to do it well. We could MVP it, spin up a new "Components" page with React/Angular/jQuery components, tweet it out and see if it gains traction.

[svinkle]

I like the separation of concerns:

• Patterns: simple demos with code readily available to study and learn from
• Components: pre-packaged, a11yProject approved code modules ready for dropping into a project

And the badging system is underway via #531. These will be applied to both pages eventually.

[resource11]

raises hand to contribute a few React-based component patterns

[ericwbailey]

Updating the thread to say that with the redesign we've deprecated the patterns page. It requires non-trivial effort to keep current, and there hasn't been a lot of movement to do this.

I'm also concerned about the issues with developers missing context, so I think a better way is to handle patterns on a per-post basis. This aligns with the redesign's goals of focusing on posts, as well as helping to encourage and boost the presence of new and existing authors.