4 years went fast. A small self-reflection about the blog and a bit about the future of it.
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.
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.
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.
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.
Design, development and even search engines embraced the mobile first way of thinking we should probably also start to think about the accessibility from mobile first perspective. Maybe it really is time to think about digital accessibility from mobile first aspect as well.
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.
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.
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.
Where to start as a developer or designer wanting to test with screen-reader? With basics, right – and maybe with mobile first. But do not underestimate real users – they might surprise you.
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.