The European Union has Web Accessibility Directive coming into force soon and it affects basically all public sector web pages. I don’t know what this could mean for Aurelia, but some ideas:
Add accessibility testing tooling setup to the CLI.
Add testing infrastructure for accessibility regarding Aurelia. Maybe indicate somehow visually what specific points have been considered and tested.
Add sections about accessibility to documentation to this forum and elsewere.
Show notes about being mindful about accessibility in appropriate places? It might annoy, might have value as signaling.
Maybe this affects plugins etc. too if they’re becoming a part of Aurelia core offering?
The core developers are probably overwhelmed as-is already, but maybe this could be something the Aurelia project want to be signaling and paying attention about. I could imagine anything related to public sector websites consider:
Accessibility.
Long term viability of the stack used (e.g. can web components be used, the framework and tools).
I tried to find what DOs and DONT DOs there are, a checklist or something, but couldn’t find any. Maybe something to start gathering?
Timeline
- New public sector websites must conform by September 23 2019
- All public sector websites by September 23 2020
- All public sector mobile apps by June 23 2021
Are we talking here specifically about aria attributes and other fallbacks for various readers? Super helpful to have your links but honestly I’m still not getting the bottom line what is needed from a technical position. Did you already find anything specific Aurelia could do?
I think it’s anything that fullfils the EU criteria, which includes also Aria.
I should have been clearer my intent was to start discussion and toss some ideas what could be useful in Aurelia context in general and not going into specifics as I my understanding of the technical requirements are fairly shaky and I don’t know anyone who is better in this regard. Though I noted a few things, such as perhaps adding accessibility testing tooling in the CLI.
This is partially the point too. It’s not easy to spot if the components out there – in any framework – have considered specifically this thing. It may be the way this is considered is that the teams implementing this with these requirements do their research and design on that and pass the folklore onwards.
Even if not any framework has considered this, what could be the “avenue of improvement” for Aurelia? From my very limited perspective it looks like the more knowledgeable people of this are not programmers so creating inclusive feedback channels would be something. One idea I just had is just have a list of Aurelia components on a page, create an automated feedback channel and ask people using this tech to review and give feedback. Maybe not just plain components but also common designs.
ok so pretty much what I thought it’s still a bit flaky what really has to be done. I’m definitely not experienced enough with ARIA attributes, but as far as I understand it’s still the go-to-solution for supporting screen-readers etc.
Now Aurelia doesn’t limit you with binding to existing html attributes, which aria-* are. So feature wise I’m unsure what we could offer to help even more. I mean certainly some decorators for custom elements (to define the aria-role) and attributes (to define the aria status/properties) would be an option, to automatically create ARIA attributes, same maybe applies to bindables. The real point though is what you described with tools to check for accessibility, which in turn are not tied to a specific framework but more on a generic level. Moreover the full overview of best-practices with ARIA might be overwhelming.
So most of the things around ARIA are a great candidate for a custom plugin, which as you said, if supported enough could be promoted to an official plugin.
There is more to it than just ARIA attributes. You probably noted this already, but I’ll continue hopefully for the benefit for the larger auedience that it’s not just I can use semantic accesibility features in Aurelia, JS and CSS features in well behaving way (combined with meaninful tagging hierarchy). I was just reading https://inclusive-components.design/cards/ by Heydon Pickering and even that is more like a glimpse.
Accessibility appears to become very important and people who know seem not be to one’s usual programmers. While it makes, I think, sense to add accessibility testing tooling readily set up to the CLI and add notes to the documentation and that kind of things to make the programmers more aware of it, it may also be worth considering if there are other ways to get knowledgeable people interest on Aurelia and help move their field forwards together with Aurelia. Unfortunately I’m not an accessibility expert nor do I work that much with web programming so I’m more like a random dude writing this here.
I’ve done a lot of work around making Durandal SPAs accessible, as Australia has required WCAG AA compliance across government sites for a number of years now. The big issues I have found are:
automated accessibility testing is very hard (we don’t do it)
JAWS is expensive (my department insists on using it in spite of NVDA)
Supporting IE/JAWS along with Firefox/NVDA is a nightmare. Fixing an issue in one combination can break it in another.
SPAs can have very interesting behaviour when it comes to live regions (get your live regions on the page as early as you can, and leave them there if possible).
Aria is pretty good, but if you can get away with using symantec HTML and regular attributes - that is far more likely to work. For example, use label with a for attribute in preference to input with aria-labelledby - or nest the input element within the label element.
My view is that the best thing to do is try to ensure your code is standards compliant, test with modern browsers, and test with NVDA. Support JAWS on a “best effort” basis.
The simple things make the most difference:
ensure labels / fields are linked
make sure your headings are in order
do not surprise a user by moving focus to odd places
if you do something outside of a normal UI pattern, use sr-only (bootstrap class) or similar to announce it to the user.
Your notes here seem to be more than one can find on many SPA forums (though I haven’t looked too hard). Considering your other thread about Aurelia being a hard sell in your work place, would it help to have a section dedicated to usability? I could imagine it would help, especially if being visible and easy to augmented with new information and tips.
I concur semantic is better than usin ARIA if possible and there are writings about it on the web. Those writings either aren’t so easy to spot.
