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.
Tag: QA
Latest posts:
Some accessibility issues originate in code. And when design is being recreated with code it may seem to work but when thinking about accessibility we may notice that it only works for some users and not for others. I’ve decided to describe some common accessibility fails that are on developers.
What would I want from my Accessibility-as-a-Service provider? What would be the ideal here when we know that automatic testing is absolutely not enough? We must also get people as a part of the service – accessibility specialists and people with disabilities. And when done from start to end it is way more efficient compared to only using it at the end.
Time flies and this blog has now 100 posts. Counting posts does not count for much but I try to consistently write about accessibility to think out loud. I also tried to summarize some quite special thoughts about complexity and how accessibility must be a team effort to be successful. On the end I also added some stats…
Quality Assurance must get their hands on screen-readers and other assistive technologies on multiple platforms, besides understanding acceptance criteria for WCAG and really get the whole accessibility aspect.There is no other way. No shortcuts here.
Defining testable conditions on multiple levels will make development and testing more effective. This is when acceptance criteria is useful.
Some reflections on my newly acquired Web Accessibility Specialist certification and a mention of Neuralink that will be demoed today and can have positive implications on accessibility as well. If used correctly.