2 years and 100 posts published – quick retrospective

Note: This post is older than two years. It may still be totally valid, but things change and technology moves fast. Code based posts may be especially prone to changes...

(Read 491 times)

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…

I’ve just found out that my blog now has hundred posts and is two years old and decided to do a quick retrospective about the blog itself and some thoughts about complexity of accessibility and the need for team effort.

This blog is not a collection of academic articles and if you read some posts you noticed that quite fast I guess. Sometimes I can also be wrong, especially when I investigate things that may be subjective. I will get to the details, but please let me know if there is something that you do not agree about. I will appreciate any subject related comments with arguments.

I write in my spare time, mainly for myself, as a log, but if anybody can get something out of it then I can just be more happy. As a non-native English speaker I probably make a lot of grammatical errors as well. Please take my apology for them. And if they really hurts you in any way please contact me and I’ll do my best to fix them.

Blogging is not so difficult, we have the technology behind, we need some time to write, but I am not a professional blogger, so I do not ask experts to read before I publish, I do not do keyword analysis for the search engine and I really just write what is currently on my mind. This post is the same, I just wanted to reflect on some thoughts of mine and write them down in the open. More about the accessibility than this blog. This blog is just a product of my focus on accessibility and only a tool to explain my path.

Accessibility – it’s simple until it is not

Accessibility is simple and complicated at the same time. Quite often it depends. Often it seems easy but can be difficult, especially when you really think of all the users and all the ways they can access the content.

Let us take the first WCAG success criteria – alternative text. And let’s discuss the most basic application of it – a simple image in an article. Does this image deserve an alternative text or is it just a decoration? Is it really a decoration? What is actually a decoration – are images that add to the “mood” and set up some kind of emotional scene really decorative? Can be but can also not be. It depends. As so many other things. I am still having discussions about alternative image descriptions and sometimes I find myself on different side of the argument. And it is OK. As it is a very subjective thing. Some people are more rational and hate such “mood-setting” images and on the other side we have also people that want to get as much as possible information about all kinds of images, as long as they are not only bullets or arrows.

Then you also have to think about the search engine. No alt text on an image is not the best way to range in the search engine, that’s a fact. But would you really like to have your “people smiling when partying on a boat” to drive traffic to your page that is offering boat loans? Maybe. It depends also on your marketing strategy. But maybe all you will get is somebody borrowing your image for some school project. You never know really. But again – if that image is maybe an image of the boat your company made and it has your logo on the sails – then it can be another story. The decision path can be difficult for images that are maybe not quite decorative but some can argue they are. Some people will argue that they will absolutely hate an alternative text on a image that only adds to “clutter” – “if I am there to check the bank rates, I really do not care about happy people on some boat” can also be a valid argument. On the other side screen-reader users can easily skip this text if they want, so there is also that aspect – “I listen to first few words and if I think it is clutter, then I just skip it” may be the best option for majority.

So – some simple things can quickly be very complicated. It depends…

Would you use a input type range for a loan page? It looks perfect – an user can drag or even use the keyboard to change the value of the “slider” and we can play and add A/B testing on it’s default value and we can even style it (to a degree). Then comes the testing. Seems very good, I even get my volume keys on my mobile phone to change the values. How cool is that? But, hmm, wait… Why am I constantly hearing values in percent? I would not like to take 55% of the loan, I want 5500 euro. This is strange. Then we do a bit of research and found about problems that occur when some HTML is not supported on all devices. We are quite used of it in the web development, but this one is really subtle. Can we do something about it? Well we could create a “slider” from scratch, with ARIA and JavaScript. In theory! Yes – there is currently not possible to implement same user experience for the input type range with ARIA and JavaScript alone. There is no way to catch the events when using a screen-reader. So what will we do? Will we neglect some users? Well, we can offer them an alternative and use a old-school input type text or maybe even input type number beside “slider” and make them move “in sync”. But maybe our user interface designer will hate that. And here you go – simple can be often complex.

Shared responsibilities are the only way to implement sustainable accessibility

I will repeat it once again – it is not up to front-end developer alone to define how will the interface of the widget work with keyboard and screen-reader. It must be a common responsibility based on best practices, patterns and limitations of the platform. And this means that all involved must dedicate some time and get into it:

  • best practices – don’t make users think too much, make it natural for them. Even for keyboard only and screen-reader users that is,
  • patterns – again – common and understandable patterns that do not reinvent the wheel in a new way are best,
  • limitations of the platform – good designers and good developers use them to make things work and make them work for everybody.

Sharing is caring, and I can detect a lot of it is happening in the web development. Sometimes that can also be a problem. Some dependencies introducing problems to users with disabilities and making it more difficult to use the services for them. Sometimes over-promising open source components that “everybody” is using because they can just install it and use it, but nobody really tested them and make them accessible. And sometimes aesthetics that wins over usability and common patterns. Design as art alone instead of design as art with respect to limitations. Component design thinking makes accessibility much easier. Re-usage makes things more robust and cheaper. But investment is needed. Designers must invest into understanding the platform limitations and how to make design that works for all. Developers must stop abusing ARIA and attaching it all over the place, thinking ARIA alone can repair otherwise broken user experience pattern implementation. Trying to over-engineer things.

Cooperation is the key. The worst thing is to work totally independent – designer sitting alone and just sending the designs to developers, then developers developing alone and delivering to QA to test and then go back to fix issues QA found. I think the only effective way to deliver accessible products is to cooperate – only whole team can make it work. And ideally they should include people with disabilities and not only single disability, but also at least knowledge of other as well. Including only blind users, for example, can also make some problems down the line. We can land with products that do not work well for colorblind people. Or maybe sighted users that use screen-reader because of their dyslexia. And so on. So cooperation should cover also users. But would we need all different users to make a simple navigation expand and collapse? No, we would potentially throw their time away. Because some patterns are known and just work for everybody. No need to re-invent the wheel or warm water, metaphorically speaking. If there is a known, well established and tested pattern – please respect it and use it. And do not waste valuable time on it. Time can be spent on much more important things. Like those custom widgets that we absolutely must have because there is no better way to do it. No simpler way. Don’t use ARIA is the first rule of ARIA. Why? Because native HTML probably already covers the accessibility. But please check that it does. Not everything works for everybody.

Some statistics

First blog post was published on 14th of August 2019 and from that day 1663 unique visitors visited my blog. Approximately 56% of visits come from United States of America, 19% from Norway, 4% from UK, 3% from Germany, 2% from Canada and so on.

It’s against all the trends but it seems like 92% of users are on desktop and only 7% on mobile. Others on tablet. That’s a strange statistics in 2021 but let’s take Googles word on it.

Majority of users find this blog on Google, no surprise there, followed by other search engines.

I don’t have a lot of returning visitors (my visits are excluded from statistics on multiple levels and I only use incognito mode to check on things), they count only 4% of all users.

Five most popular blog posts at this moment are:

  1. Cookie consent banners and overlays – thoughts on accessibility, usability and SEO (read: 1060 times)
  2. The importance of keyboard for accessibility (read: 307 times)
  3. Use of bold and italic to highlight importance for some words – semantics is not always passed to screen-readers (read: 294 times)
  4. Acceptance criteria and accessibility (read: 249 times)
  5. Mozilla Developer Network (MDN) – learn about Accessibility from community behind Mozilla Firefox (read: 240 times)

Thank you for reading

Sincerely thanks for reading. This blog does not get many traffic and it is not my intention to make money from it. It is more about my path towards better implementations of universal design and accessibility. And to log, summarize and reflect on some theoretic and practical discoveries I make along the way. I will not promote it and there will most probably never be any ads here. And yes – I need to invest a bit in the visual design and images. The plan was to write as soon as possible and improve the design later, but I still prefer content over form, so I am in no hurry. I love to take photos otherwise but I am not so keen on editing and optimizing them and that part will have to change, so that I will brake the walls of text into more readable pieces of text for sighted users.

Thank you and I hope that you will come back, I really do my best to post at least one relevant post per week.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: