4 years went fast. A small self-reflection about the blog and a bit about the future of it.
Tag: Screen-reader
Latest posts:
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.
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.
Sometimes it’s simple to make a feature with JavaScript but not so simple to make it consistent for all those screen-reader and browser combinations. In this post I describe how I tried to update some live regions and the order in the DOM was not respected. Solution was simple, but it’s easy to forget about it when it works visually.
Mobile native applications are often with no headings. Sometimes even have visual headings but are missing on the semantics. Screen-reader users can and also like to navigate via headings, so we should be responsible and use them. They are supported on both iOS and Android.
Navigation between pages is so natural for us that we don’t even think about it. And obviously it can also be forgotten when using newer technologies like Single Page Applications. Although a decade old, some are still not really accessible as navigation is not announced to screen-reader users. Let’s check what works and maybe have a conclusion.
Global Accessibility Awareness Day number 11 is soon here. It’s my third one and this time I have a bit different plans for it. An online mobile screen-reader app, analysis of Slovenian accessibility and ask me anything session instead of webinar.
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.
Everybody seems to publish videos online and that is not so strange with modern mobile phones all around us. But to make a video accessible we need to invest some time and effort, otherwise we risk that some people will never get to our messages in the video. I try to summarize the basics and also provide some resources that can go beyond.
I try to summarize on the hard parts of accessibility as I detect them. Some parts of digital production are actually simpler to make accessible and some are not, so reflections on that may help you to invest resources correctly.
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.
Accessibility is a cross-role responsibility and this also means that documenting it has to be a common task. Cooperation and common grounds makes the teams efforts much more effective and it can mean a big difference when relevant documentation clarifies also the minor important decisions about specifics of accessibility.