I’ve learned that WCAG can’t be changed a lot and that only additions are allowed. Now I’ve read that WCAG 2.2 will have the 4.1.1 success criterion (parsing) removed. My first reaction was – why and how will we work with problems in HTML then? On the other hand we should probably be happy we can focus on other problems that are more related directly to accessibility.
The journey from content creator to end user is quite long. At least in terms of different software that needs to deliver. And as we all know – software has bugs. And sometimes even so called features that can actually be called bugs as well. So please test and if we find a problem – report it, so that we improve the accessibility one step at a time.
Trying to set a baseline for making more accessible custom interactive components. Yes, you should refer to whole WCAG and I refer to it as well, but this can be used as a good baseline as well. Hope it can help somebody.
We are most probably failing a WCAG success criteria 1.4.10 Reflow because of CSS’s inability to fix word breaks for us. What can we do to allow grammatically correct word breaking when our browsers can’t help us yet?
Common effort, interdisciplinary competence and early dialog can be the only best practice for assuring the accessibility of the final product. If we leave that team members live in their own roles then we are almost surely to fail and get into situations where the issues on the end prevent launching accessible products and flood the team with issues. Cooperation and dialog are key!
Where to start as a developer or designer wanting to test with screen-reader? With basics, right – and maybe with mobile first. But do not underestimate real users – they might surprise you.
It is possible that our website is 100% WCAG compliant and still not accessible to an assistive technology user. WCAG alone is not enough, we must test manually as well.
Scaling down web browser is not enough. We should really test with physical devices and with at least Android and iOS based devices. UI and UX tests are important but so is testing accessibility with mobile screen-readers.
Before we start with a review we should have a plan. We should think of providing real value, not just covering compliance. We should define real goals and lead to real results and improvements.
Why are we not encouraged to use ARIA everywhere? Because it is a last option – if we are not able to find a native semantic element, or if we want to create something special, then we can use ARIA. But it should be used wisely!
I wanted to expose sweet points from the Making Facebook.com accessible to as many people as possible article that was published on 30th of July 2020 as it is an excellent example of continuous and from-start accessibility in my opinion and we should all implement at least some parts of it in our work-flows.
Starting soon lowers the costs on the end. And minimizes potentially unneeded dialogs that should already be a part of the design process from before.
I have done some quick practical testing and research about cookie consents accessibility, usability and also some testing with search engines – on some websites in Europe, to see what are consequences of cookie consents for users, owners and search engines.
My reflections on the process. And yes – testing early is a requirement. Developers should also use screen-readers to test their components, templates etc.