The easiest solution to website inaccessibility
We audit a lot of inaccessible websites. Many are created by FTSE 100 companies. They are often asset-rich and committed to accessibility. This begs the question: why are the websites inaccessible?
The web standards provide the tools for creating high-functioning, accessible websites. It is true that not everything can be made accessible from standard-conformant HTML. Multimedia can be particularly challenging. For example, videos can benefit from audio descriptions and these require more than code. However, well-structured, semantic HTML provides considerable out-of-the-box accessibility.
For example, the best way to ensure that a link is accessible is to use an anchor tag. Consider the work required for an accessible native and custom link. This is a native link:
Native link example:
<a href=”http://www.acme.com”>Acme Home</a>
The alternative is much more complex. This is a custom link:
Custom link example:
<span class=”link” tabindex="0" role="link" onclick="goToLink(event, ‘http://www.acme.com')" onkeydown="goToLink(event, 'http://www.acme.com’)">Acme Home</span>
The work required to get similar results is widely different, however. The custom solution is also more dependencies. It is significantly reliant on custom-made CSS and JavaScript. It requires more development time, degrades less gracefully, and is more likely to break.
Why make development harder? It is the result of feature creep. Organisations want far too much on their websites. Succinct websites are gone. It is common to have accordions, tab panels, and modal dialogs. But all these do is side-load content.
An accordion, for example, toggles the visibility of content. It is not available in the HTML specification. Ultimately all it does is hide content that, if displayed by default, would clutter the page. At the same time, it can drastically hamper accessibility.
Ample effort is dedicated to fixing inaccessibility. However, it is slow-going to fix problems created websites being bloated. It is considerably more effective to champion accessible practices throughout development. The result is slimline, well-curated and performant websites.
The alternative is embedding complexity that creates inaccessibility and won’t be used. User testing at AbilityNet indicates that users avoid anything complicated when simpler options are available.
This includes features like date pickers. It’s easier for users to enter this sort of information manually. Give them a standard input field with an input mask (e.g. dd/mm/yy) and they can complete the task in milliseconds. That will never be true of a date picker.
Users must often mouse-click through years, months, and scan through days on a calendar to find a specific date. The design pattern looks more visually fit-for-purpose. But it is functionally much more complex.
The same is true with content in general. The more content on a website, the more difficult it is to use. Consider screen magnification users. Zooming into a page that is bloated with content can be extremely disorientating. A client might ask: “How can we make blocks of text easier to perceive for screen magnification users?”. The answer is: “Have less of it.”
What makes matters worse is that complexity can require breaking the rules of accessibility. A cornerstone of keyboard accessibility is to never trap focus. Allow users to keyboard tab through everything. However, modal dialogs necessitate trapping focus whilst they are on screen. It would be confusing to tab behind one of them. Best practice for a complex pattern is to ignore best practice.
We often see developers attempting to remedy this with ARIA (Accessible Rich Internet Application). This is code that can be added to boost the accessibility of patterns that cannot be made with semantic HTML. However, as WebAIM states: Almost every report we write includes a section cautioning against ARIA abuse and outlining ARIA uses that need to be corrected or, most often, removed. Ironically, this is often followed by a list of issues that can only be addressed with ARIA.
– John Whitling, WebAIM – To ARIA!
The more we allow feature creep, bloat, and retrofitted ARIA, the harder it becomes to create robust and sustainable websites. A hack used to visually declutter a page can be broken by a single browser update. Of course, small updates will always be required. No solution works forever. However, the issues that we identify at AbilityNet are symptomatic of fragile websites. They are committee-designed websites.
Inaccessibility is caused by a desire to add more content. The easiest way to create accessible websites is to say no. Create lean designs and stick to them. Cut your copy in half. Then, cut it in half again. Be elegant. Your accessibility will skyrocket.
Originally posted here
