The Evolution Experience [A to Z a11y]

In the Beginning

Well, not the Beginning as such, rather the letter E which in this A to Z of Accessibility is for The Evolution Experience.

It’s difficult, when writing these pages, to avoid “catchphrase overload.” This section could be easily have been dubbed “Progress Over Perfection” but I wanted to get this in early on so I could encourage and exhort you all to embark upon the expedition that is Accessibility. OK, that’s enough E’s now.

This article is not tech specific but rather about the Accessibility Journey. I will touch on areas of the Power Platform etc, but this applies to everything.

Mission Impossible

Anybody who has heard me talk about accessibility will know that I make it abundantly clear that you cannot achieve perfect accessibility. Put plainly, It Just Is NOT Possible*. What you do for one person may make things worse for someone else.

* When I say not possible – if you spent millions or more then you might manage to find the unicorn of accessibility. It’s not within the reach of most of us though, and nobody is going to spend millions on this 😢

If we wait to achieve this mythical nirvana state of perfect accessibility, we will never start making changes. Instead, our focus needs to be making a start. Taking a single step is better than waiting and then taking none.

Start Small and Build Better

Later in this series I will be detailing some easy and quick ways to immediately improve accessibility. To get a feel for some of the quick wins you can check out the talk I did at the Urdu Hindi Bootcamp, which I’ve handily embedded below or can be watched on YouTube by clicking here:

Implementing a small change, either as an individual or across a whole team, is not a difficult thing to do. It can open the door to much better engagement and allows you to move along in your accessibility journey and feel the wins.

Documentation <yawn>

I don’t think there’s many out there who have a development standards document that is adhered to completely, if at all. A coherent and clear way of building and designing anything from tables to dashboards, apps to web pages. In the same way as companies have, or need, document temples we should have “development templates” that define how to build and how to do things. This ensures we deliver “on-brand” and in a consistent manner and helps those who don’t know what best practice is or how it should be implemented.

A quick detour on the document templates. PLEASE check these for accessibility, including the Slide Masters in PowerPoint. I get in to trouble because I will deviate from the standardised templates when I find accessibility issues. There is no reason why company wide templates should not be accessible. It lays a bad foundation for content and reflects poorly on the organisation.

Anyway, back to Development Standards.

These traditionally lay out things like:

• Naming conventions
• Commenting standards
• Screen layout patterns
• Dashboard layout
• Colour schemes
• Versioning
• Deployment
• and more

Adding accessibility to this sets out the expectations from the beginning. It can also provide a clear reference for people, so they know how to build with accessibility in mind.

The Evolution of Experience

As with all things, we start with the first step and learn as we go. This rule applies to accessibility. It may be a process rather than a big bang, but something is better than nothing. Take a few steps and you are already further ahead than you were before (sounds obvious I know!)

Start with making sure that your Power Apps controls all have Accessible Text set, or your Power BI reports have Alt Text configured. Simple things that require a bit of a mental shift but will quickly become a habit and will lead to better deliverables.

As you go along you learn more and build that in. The experience you gain leads to the inevitable evolution of what you deliver.

The Most Important Experience

In all of this, the single most important experience is the Lived Experience. To drop in another catchphrase:

People who use assistive technology, or need accessibility in the tools we build, should have the biggest say in how we “do” accessibility. The challenge is that, for many, they have got used to working around the lack of accessibility and can often hide their need for assistive tech.

We need to build cultures where people can speak out and have their voices heard. Encouraging those who live with this day in and day out to be a core part of what we design and build.

I’d love to add stories and information here on how this can be done as it’s something I am still learning. If you have any ideas or experience, then please get in touch so I can expand this section!

Thanks for reading A to Z a11y – The Evolution Experience😊

Thank you for reading The Evolution Experience. This post is part of my [A to Z a11y] series the “A to Z Accessibility: Power Platform Edition”. Click here to go to the introduction article where I will be posting a Table of Contents, or simply check out the Accessibility section of the website from the top menu or by going directly to the category page here.

Content in this series is © Mike Hartley. I am happy for folks to quote or reuse snippets (with attribution) but this has taken a lot of work to compile so please do not copy whole sections. If there are any corrections or suggestions, then please use my social links to contact me. I am always happy to add additional content and remarks with full credit given. Likewise, these pages will evolve as my learning and understanding grows, so make sure to keep this bookmarked