Tables are sometimes critical for understanding, and even if HTML supports quite complex tables we should keep them as simple as possible.
Tag: HTML
Latest posts:
We need to be aware of the limitation of the tools to be able to use them properly and to prevent any bias.
Question of dealing with conflicts between aesthetics and accessibility comes up a lot and sometimes it’s easy to just let one side win and be done with it. I think that we need a cultural shift to have both of them.
Sometimes I see complex web components copied to native mobile applications and often they are the cause of accessibility issues.
Everybody knows that we must not use aria-hidden on interactive elements. But why is that a problem? I decided to check for myself, so that I can explain it better the next time I will be asked.
Personal reflection about my encounter with web and accessibility, how I was ignorant of it as well and how I think we can’t be ignorant any more.
I feel that design is too focused on the visual parts and therefore the burden on non-visual design falls on developers. What can we do to improve this? To fill the gaps?
9 new success criteria and one less in WCAG 2.2. Removing 4.1.1 from WCAG 2.2 impacting WCAG 2.0 and WCAG 2.1 as well (can’t fail 4.1.1 anymore). Even if three new WCAG 2.2 success criteria are on level AAA I don’t see reasons to not implementing them as they bring much value!
Sustainability and accessibility are absolutely interconnected. Recent sustainability guidelines, although still in draft version, are quite often referring to accessibility, so I wanted to expose parts where accessibility is beneficial to sustainability.
Sometimes best practices are passed as WCAG requirements and that can make accessibility more difficult for some people to implement. We need to understand what WCAG actually requires and what it does not before we try to impact other people.
Inert is still useful and although we are slowly getting native dialog we can still benefit from using inert when we don’t strictly use dialogs or modals.
Just a quick brainstorm when checking a design wireframe for potential accessibility issues, finding low level problems that may be solved way earlier than we may think. Maybe even before designer became a designer and before developer became a developer?
Once again a discussion I had on problems with headings after an accessibility audit. Can we get it right and can we have a sustainable solution? I believe so!
When developers discover ARIA and try to misuse or overuse it we get more problems than we may have before. It’s not just that, even if they do everything correctly we risk to have an inaccessible product due to missing support of theoretically great ARIA.
Please forget about automatic document outline and plan accordingly. Make it work for people and not for search engines. It’s once again a team effort – design, develop and content.
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.
After giving a talk about accessibility and discussing the lack of awareness I decided to reflect on some thoughts in this post.
Are we ready to use native HTML dialogs in production? As often – it depends. Please don’t take it against me but it really depends. Some users are still forced to use older browsers, polyfills seem to be problematic, so most often we are still stucked with ARIA based dialogs. For now.
Accessibility tree in browser and screen-reader’s speech logs are extremely valuable tools when we want to check how HTML, CSS and ARIA translate to assistive technologies like screen-readers, no doubt about that. But please make sure to go through to the end – do listen to your screen-readers and in different combinations with browsers. As sometimes that’s the only way to find out about real problems.
What would I have in an automatic accessibility testing tool if I could have anything that is possible with today’s technology?
Well, I would start at the beginning – clear scope and known priorities is a start and sometimes we can’t really cover all that when we have to choose where we need to focus. Next, I would like to teach the tool, so that it will be more and more independent. And because I like to stand for my decisions – I would like to use the blockchain to prove my efforts and fixes. Words can be empty, deeds talk.
Before you order your accessibility audit you should read this article of mine. I try to be objective and constructive and present the good and the bad, the strengths and the weaknesses of accessibility audits.
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?
Some improvements can be detected and I also added some thoughts of mine about the parts that are not very obvious. Interestingly – e-commerce is almost worst – and that really is a surprise when we think about how much do they invest into ads and SEO, just to get some new users.
Is it okay to give a heading level 2 the style of level 3 but keep the semantics of level 2. Well yes – but as often with accessibility – it depends. It’s not up to developers to set it in stone and it is for designers and content providers to decide when appropriate. Content is once again crucial.
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.
Why do status messages matter so much they deserve it’s own success criteria in the WCAG? Well, it is just a minimum – all users deserve to be informed when something important happens, also users of screen-readers and other assistive technologies.
External agency made an accessibility audit. It provided a lot of possible solutions. In this post I try to make it easier to act on this audit. Breaking results into responsibilities, then prioritizing the issues and finally estimating and fixing them can be one way of doing so.
If you own an online shop I really suggest that you make it as accessible as possible. European Accessibility Act will require it from you, but let’s rather think about getting more customers, non-discrimination of people with disabilities and better search engine optimization as the main drivers for making eCommerce accessible.