marcus-herrmann
commented
6 years ago They prefer examples directly in their chosen framework as that is the level of abstraction they work at and they don't want to make the mental model shift. Especially when accessibility may be enough new concepts for them to grapple with. [...] Hence this project is born. If I understand the goals properly?
Exactly, that was the reasoning behind it.
We need to make it clear that any examples we provide are effectively implementation details that require design decision to have been already made, with user validation. There is a real danger with leaving accessibility to the development stage of producing accessible features that are not usable.
Thank you for formulating exactly what I had in mind. We have to stress that this project, if launched, is not a solution for everything - but instead only supports the development step of a - hopefully - already inclusive software project.
I've been thinking about providing developers more framework specific guidance for a while so am excited to join this project.
On the face of it, good practice in accessibility coding (both static markup and dynamic code controlled behaviour) should be largely independent of any frameworks. All that should be required is providing minimal, browser consumable examples. This would clearly cover all the topics without framework specific clutter in a way that can then be easily transposed onto individual frameworks.
Apparently confirming the generic nature of accessibility is that after recently reviewing the accessibility information provided with many frameworks it's clear they have little to say on the matter. I found framework specific accessibility features or barriers to good accessibility caused by the frameworks themselves.
However, while there is merit in a generic approach, my strong impression is few Single Page App (SPA) frontend developers work down at the browser metal. rather they use a framework (or library), possibly one of the big 3 - React, Vue and Angular. They prefer examples directly in their chosen framework as that is the level of abstraction they work at and they don't want to make the mental model shift. Especially when accessibility may be enough new concepts for them to grapple with.
So there appears to be merit in providing a set of examples that are coded to specific frameworks and ready to consume as examples of best accessibility practice. Hence this project is born. If I understand the goals properly? We can help developers code good accessibility using the tools they are familiar with.
But, and it's a really important point, users accessibility preferences can only be met in a way that satisfies the users and developers if the concepts of Universal Design are embraces from the start of the design process. We need to make it clear that any examples we provide are effectively implementation details that require design decision to have been already made, with user validation. There is a real danger with leaving accessibility to the development stage of producing accessible features that are not usable.