Not really surprisingly – aXeSiA did not won axe-hackathon. And I never dreamed that it will. It was just an experiment for me personally. But this will not mean that aXeSiA is retiring – I will make it a tool I can use often. And a tool I can really tweak as I need and like. Congratulation to other projects and especially Inclusiville. If I had the time I would be happy to work on all other projects as well as they are really good.
Category: Accessibility testing
Latest posts:
aXeSiA – my open source contribution to accessibility testing and axe-hackathon. We all like to use browser extensions to test the pages but aXeSiA makes our work easier if we want to automate it.
We remember the rule for alternative text on decorative images, right. But is it really so clear what an decorative image is. Sometimes SEO wants us to have alternative text for images that do not directly add to the information. Should we do it for the bots or should we save time for screen-reader users? It depends. As always…
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.
Extremely valuable documentation that reveals some interesting points about future of Web Accessibility Directive monitoring methods, tools and also some less clarified reporting matters. The accessibility statement automatic analysis will most certainly also have a central role and it is worth following on the Accessibility Conformance Testing rules that are the engine of all automatic tools out there.
Is it better to hire external consultants for accessibility assessment or is it better that it is made by the software vendor? I would say that both has its pros and cons and that combination works best.
Just a short explanation to all the developers out there that may not understand the need for skip to content links.
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.
Defining testable conditions on multiple levels will make development and testing more effective. This is when acceptance criteria is useful.
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.
Social media is one of the most used internet services. And people with difficulties are users too. And as they should have the right to work as well – they do use LinkedIn. So it must really be accessible. But, is it?
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.