Latest posts:

Posted on:

How to know that a website or app is really accessible?

To claim that our product is accessible needs more than just WCAG audit that did not discover any fails. Real users, people with disabilities are the only one that can really reflect on the accessibility of our products. That’s why we should include them in all reasonable parts of our production processes. Otherwise we may think we deliver accessibility but the truth can be opposite.

Posted on:

Majority of accessibility problems originate in design, and then code, low- or no-code

Inspired by others – I reflected on the origins of accessibility problems in design. It’s not so strange when we think that design is the implementation plan and if plan is not accessible then the final product will most certainly also not be accessible. Code, low-code or no-code alike.

Posted on:

Accessible content is so much more than code

Sometimes people claim that accessibility is the responsibility of development and code. I disagree. It is a team effort and it can only succeed when whole team knows what to do. Content is king and if we start and end with content it can make the teams accessibility efforts much more effective.

Posted on:

Problems with automatic accessibility testing

Automatic testing of software is brilliant. Saves a lot of time and effort, prevents problems soon and makes our products better. But when trying to automatically test accessibility we need to know about the challenges and problems before. Some tools may even produce wrong results and some tools may report everything is perfect when they can only test up to a third of criteria.

Posted on:

Sticky and fixed elements may cause huge accessibility problems

Web is full of sticky or fixed elements and they may add to usability for some users. But if we think about variety of different users we may quickly note the possible problems for them. Covering too much screen, covering important other elements, or even blocking users totally can be prevented with proper planning and testing. This article tries to map the problems as a first step to proper awareness.

Posted on:

Alternative text for images on the web – best practices for developers

The more I know about alternative text for images the more I understand the complexity of it. There are differences between users and content creators about decorative and informative image objectives and developers should never decide if image will be decorative or not. HTML standard includes a lot on this as well and should be read by more people for better accessibility and better web in general.

Posted on:

2 years and 100 posts published – quick retrospective

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…

Posted on:

User experience is beyond visual and must also cover vocal

Vocal user interfaces come to my attention when playing around with my phones voice assistant. I treat screen-reader as a vocal user experience as well. They are not very related though and that came as a surprise for me. But voice assistants have giant impacts for everybody, not only from accessibility perspective but in general when thinking about humans interacting with computers.

Posted on:

Accessible Rich Internet Applications on mobile devices

I wanted to describe the importance of ARIA for mobile devices. Especially when we have to be careful with ARIA and maybe just accept the fact that native HTML element can be much better choice. Sometimes graphical design should embrace the limitations that styling native HTML elements bring.

Posted on:

Developers should test with screen-readers

Every (front-end) developer should add screen-reader to their tools. Screen-reader experience can really help us make products more accessible and also be better at our coding. Combinations of screen-readers and browsers can get over complicated, so it is important to think if code we write is supported for majority.

Posted on:

Screen-reader users don’t tab through your site

I organized an accessibility workshop for our front-end and full-stack developers, user interface and user experience designers and others involved in digital production. This post will concentrate on screen-reader (SR) users way of navigation because it may surprise non-screen-reader users quite a lot.

Posted on:

Should we add alternative text to a decorative image because of search engine optimization or not

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…

Posted on:

Correct heading for the headings – what is important for accessible and search friendly heading elements

There are still some myths out there about what we can and can not do and there are also some best practices around use of headings. Please do use them is my advice, but it is not a thing for compliance and SEO itself. It is more about usability.