Today, on this rainy, cold Netherlands saturday afternoon the idea came to me. I hope you will enjoy what's ahead, and maybe even learn a thing or two.

Umbroken

I got involved with Umbraco because, as a blind web developer, I was applying to jobs in my area after being let go from my job at the time. I applied to a place that was using Umbraco CMS, something I'd never heard of until then.

Job interviews going as they do, I'd hear more by the end of that week and when I got home, I started researching just what this Umbraco thing was.

Fast forward a bit, and I got involved in a now somewhat (in)famous discussion on github regarding a slew of accessibility issues that were uncovered by an audit that had been done a few months before.

Doing more research, I encountered a Dutch article written by someone at Perplex Digital, which is where I currently work. You may have heard of them 😉

That article gave me the impression that at least this company cared a lot about their accessibility, which made me apply for a position there. It was when they wanted me to do a quick trial project to test my skills as it were, when I saw just how broken some of the things were, and to some degree still are.

At the time the content tree and settings tree, pretty much any tree, were pretty much completely unusable with a keyboard, let alone a keyboard and a screen reader.

A lot of buttons were only denoting their function using an icon (gear icon for settings etc). Icons aren't read by screen readers unless you add a textual alternative of some kind, so these buttons were read as " button" or a link labeled "Umbraco".

Modal dialogs appeared, but at the very bottom of the DOM, which means screen reader users often didn't even know anything had happened.

Context menus appeared if you hovered your mouse over the thing in question. Screen reader users do not use a mouse. To get a better idea on just what needed to be focused on first, I went through the basic website tutorial. The rather brutal results of that particular endeavor can be found in this gist containing my notes.

Umbarrassment no longer

Back when I first started this project, I had moments where I was seriously not sure if I'd be able to get enough people interested to make a dent in the literally hundreds of accessibility issues that littered the Umbraco backoffice. With Christmas coming up, though, I'm glad to say we've not only made a dent, but actually made some very good progress.

Some experiences are still awkward and unwieldy, we definitely aren't there yet. However, the recent 8.2, 8.3 and 8.4 updates have addressed a large amount of showstoppers that make me, as a fully blind developer, able to be somewhat productive on an 8.4 build of Umbraco.

Context menus have a button now that doesn't require a mouse. So do arrows to expand and collapse levels in the tree. A lot of apocalypse buttons, buttons with only an icon to denote it's function, have proper labeling now, so I know if I'm editing, or deleting that document type I just spent 10 minutes on. A big, huge h5yr to all of the people who helped me make that happen.

Obligatory final takeaways

This article would be incomplete without a few takeaways, some lessons that came out of this endeavor that is even now still going on. I think the biggest ones are the following:

Accessibility is tough if you have to retrofit it into an application that didn't account for it ever being a thing

The Umbraco treeview is about as far away from a proper HTML treeview as you can get, and to make it as accessible as it is now took far more work and effort than it needed to if HTML specifications were followed from the get go. According to those HTML specs, a tree view should look more like this example of a treeview from the Open Ajax Alliance. Needless to say, that is not what happened in the Umbraco backoffice. 😊

This is not an admonishment, this is a lesson. Native HTML can do a lot more than people realize, and to ignore all the work people put into making that spec is simply inviting a bunch of extra work onto yourself when it finally turns out you weren't smarter than the folks who made the spec a thing that browser vendors and assistive tech vendors alike adhere to. The browser gives you an incredible amount of preprogrammed standard behavior that users have come to expect to be there.

To roll your own is often a lot of extra work for very little gain and will very likely inconvenience at least one of your target actors, even if the design looks super sexy. Madness lies that way, beware! 😊

You aren't your target audience

A question that kept coming up in my initial research, when I was first putting Umbraco through it's paces, went something like this: " Just ....how was this missed?"

The answer is really very simple; we test for ourselves, not for our audience. Only our audience can test for our audience.

Blind people don't just tab through a website ad nauseam, we have a bunch of different ways to navigate a website that are much more efficient if the infrastructure for those methods is there. Proper heading structure, proper use of semantic HTML roles and proper labeling of buttons and links helps us do that immensely.

Flipping that statement on it's head, not all keyboard users are blind. People with repetitive strain injury (RSI), people who have trouble making the fine movements for mouse use due to a physical impairment of some kind, the list goes on. Where skip links are often somewhat redundant for screen reader users, they help these other keyboard users immensely.

Screen reader users tend not to use a mouse, so clicking an element and having the screen reader announce the correct response does not mean your element is accessible. Some partially sighted people might use a screen reader to reduce eye strain, but that is just yet another target group.

Blindfolding yourself does not emulate a blind person's experience, because you don't know how to use a screen reader and even if you know the manual back to front, it won't tell you how people actually use this tech in the wild.

All these examples really mean to illustrate that if you want to test your website or web application for a variety of needs, you will have to bite the bullet and have people with those actual needs test your application. If you do this, it will have to have the same gravity as any other UX activity.

Do you pay your beta testers? Pay these folks as well then. Do you get feedback from people with a disability of some variety? Don't play the numbers game and put it down with the same importance you would any other feedback. Yes, the target group is smaller, and also you're telling that smaller target audience they're not worthy of using your website if you mark this feedback low priority.

Finally ...remember why you are building whatever it is you're building. You wanted to help humans solve a problem. All the money you make and all the fame you gain don't change that fundamental fact.

Internationalization allows people speaking a foreign language to use your website. Security allows people to feel safe using your application. Accessibility improves the experience for all your users and makes your application future-proof. Umbraco is on the right path, will you follow in it's footsteps as your new year's resolution?

Happy holidays, everyone 😊