I was invited to present accessibility to a pretty large group of people this week. About forty persons, majority of them developers is a large group for me at least. In this post I will reflect on some thoughts that crossed my mind before and after the three hours long presentation, maybe they can even be useful for you, dear reader.
When we are young we think differently
I remember myself being at the start of my IT career, that was before my professional career in web development and when WCAG version 1 was being completed – around 1998. Making my first website was actually just playing with images.
Nobody designed the page for me, I had to come up with something that was a mix of flyers and magazines. I had to pick colors and fonts based on customer’s branding and logo. A yellow and white combination. You can probably guess that contrasts on the end were poor. It worked for me and when I have shown it to the board majority was excited. Except of one board member that immediately said – our members will not be able to read it.
I was curious – why? Everybody else in the room was happy and could read it…
Well, she said, the contrast is poor. Too weak to read for me.
And that was the first time I met accessibility, even before I really met accessibility. Poor contrast was quickly solved and I learned about importance of it. But unfortunately I needed many more years to know about other aspects of accessibility. Those were also the days that we had to use tables for item positioning and we didn’t care about responsive design. All we needed to do was to support a single resolution. 800px * 600px was starting to be popular and 640px * 480px was the standard.
I didn’t think of people using keyboards on web, nor people having to zoom in to see better and I was again caught by a surprise when I got a feedback from people that needed to scroll horizontally and vertically all the time. Another lesson learned. Once again learning about accessibility before really learning about accessibility.
I think that when we are young we often “live in a bubble” and we need encouragements to see beyond. When I think about it we should all be learning about basics of accessibility in primary school. It would make a huge difference on society – for the better.
Universities are doing some great work but still far behind needs
I’ve got a chance to meet some junior developers that just finished their university degrees and I am always curious about what they learn. Especially if they learn about universal design and accessibility. And lately I actually get positive answers – yes, we did learn something. Was not able to get my hands on what something really is but it seems positive at least.
Accessibility is a huge field. Even if we just limit us to digital accessibility and even if we pick web as our main focus. The WCAG alone is quite overwhelming first time(s) we study it. And then there is the accessibility support, different solutions, compatibility issues and so on. So I don’t expect universities to cover all that. It would probably demand full focus on accessibility alone. But it is smart to present students to the field. To at least invest some time to go through models of disabilities and how accessibility and universal design tries to prevent discrimination and enable people.
I don’t know why I am not able to find any bachelor programs for accessibility, I was only able to find master level. This is a bit weird for me as well. It would totally be needed when we take a quick look at the current market situation. And the future only seems to have more focus on accessibility, well deserved. So it’s a bit strange that universities aren’t doing more as well. After primary school we would need also all universities to help us build awareness. It’s again not only on the developers and designers. It should be for everybody that will need to bear the responsibility for accessibility. Project managers, project owners, procurement and economy, designers, content providers, multimedia producers, designers of all kinds and tastes and developers.
Developers often like clear solutions
Let’s be honest – sometimes WCAG seems too open to interpretation. It’s like that for a good reason – to allow it’s application onto multiple technologies, not only web. But on the other hand such openness is also a bit problematic for people that like their solutions clear. Clear like in the sense that there is no doubt about it. Developers like such solutions, re-testable, re-applicable solutions. They don’t like the “it depends” as an answer. It adds to confusion and complexity.
But unfortunately we have to deal with it. I guess that cross-browser incompatibility in the old days and current support for assistive technology have some similarities. They make the development of products more difficult. When we also add support for combinations we get even harder and more complex situations that needs to be solved. For example – we have a lot of ARIA that seems to be a savior for missing semantics, but if we check how much of it is actually supported and where we can quickly get ourselves into practical problems – code that seems to be OK but doesn’t really work. Or it is not supported in the most popular screen-reader and browser combination.
This may add confusion and friction when developing as we need to also test everything. It’s like in the old days when we had to check specific browsers support and find other ways to fix it if it was not supported. This can often be a huge burden on developers. And making it harder for them is not helping at all.
So not having clear solutions brings negative experiences to developers that like clear solutions. It can break the awareness that was maybe there out of curiosity. It may cause the awareness to be neglected due to deadlines and continuous delivery of small features. It just make the whole thing more difficult an adds to the unknowns. Sometimes I wish we would have more specific solutions that would help with clear answers and as little as possible “it depends”. It would make things easier to understand and easier to implement.
To develop is often to translate
To develop with code is to translate designs, data, user experience to code. So if our original plans don’t support us on the journey of the product we need to find out what things mean by ourselves. Often we get designs and they seem complete, but if we think about they are only showing visual aspects. What about keyboard navigation flows, what about invisible texts that are there only for screen-readers? They are often neglected, if designers didn’t incorporate them in the hand-off. And often the designs were approved by stakeholders and probably we can’t really get into touch with the designer to ask them about details. So it’s up to the developer to solve such issues. And if the developer isn’t thinking about them then we land with potential problems down the product journey.
Some developers don’t like to be the translators of the design’s non-obvious messages and some developers just don’t have the skills. So relying on them is very non-professional. It’s like being an architect and leaving the stairs being made by contractors without providing the plan for them.
This adds to the negative experiences and sometimes cause harm to awareness. Distinct roles with distinct responsibility and clear division of them where possible can solve this. Cooperation in common responsibility can’t be neglected, otherwise small but important details falls into random hands and are therefore potentially never released or released in non-optimal ways.
Accessibility is a team play and having good blueprints helps a lot. If we let people take responsibility voluntarily and not systematized then we are most probably failing. Not only at awareness but also at delivery.
Awareness is rising, technical solutions can sometimes be stucked
I am actually happy that we get more awareness than before. Often it’s a bit vague and sometimes some people try to take advantage of accessibility (thinking of some overlay vendors over-promising with “single line of code that gets your site compliant”). I just have to say that there is a lot of things going on in the JavaScript and CSS fields. It’s actually quite hard to keep track. Exciting but also dangerous when we think all the people investing their time to improve JavaScript and CSS and then the limited numbers of accessibility specialists that need to check if things are (still) working.
At the same time I feel that HTML is a bit stucked at the moment. At least if we compare it with JavaScript and CSS. I guess that’s logical as we can make custom components with JS and CSS, but then we have to break the first rule of ARIA – don’t use ARIA.
Awareness is rising, that’s a good thing – I only hope that it will also help with HTML improvements. We recently got native dialog elements, but it’s too early to confidently use it. There are initiatives like Open UI (opens in new window) that wants to standardize the definition of user interfaces (UI) and that’s a very good thing. But still, we need time and engagement of different people, especially browser vendors and accessibility specialists if we want it to became the main-stream of development.
Conclusion – to change the world start with yourself
It’s like with any change, not only accessibility; we need to start with ourselves and work with other people. Nobody knows everything, but there are always people that know more than me and you. So we need to learn together, encourage each-other and constantly improve. Then we will go beyond awareness and accessibility will became integral part of our production. Somewhere it already is, but it will take some time that it will be overall. Let’s do it together!
