Accessibility - a technical perspective ...and a human one

Formally, the EU standard ”EN301549” forms the basis for the requirements. The standard is largely based on W3C's recommendations in the WCAG version 2.1 standard. These documents are neatly summarized at DIGG. We do, however, also recommend that you review the new features in WCAG 2.2, which will likely become an EU standard in the future. In this article, we have highlighted what we believe is most important and (hopefully) easiest to address.

Assistive Technology and Standards

For people who need support, there are both built-in assistive technologies in operating systems and browsers, as well as external assistive technologies that can be integrated with the computer. For these to function as well as possible, your site should follow applicable web standards. If the HTML code is correct, it becomes easier for a screen reader to read out the content to the visitor. For example, it may be better to use <header> instead of <div class=”header”> and to ensure that the site's main navigation is located in a <nav> element. Make sure that all links are actually links (<a>-elements) and not buttons that navigate with Javascript. Small changes that make it easier for assistive technology to convey the correct information to the user. Also, ensure that headings on a page appear in the correct order, as this helps the user navigate the text. Remember that all content on the site should be readable by a screen reader. Text in images is rarely a good idea, and if you have video or audio clips on the site, there should be a text version of the content as an alternative.

Appearance and Zoom

The CSS code also needs to be written correctly to create an inclusive site. People with impaired vision often choose to zoom the site to make text and images larger. Therefore, ensure that your site works with a higher zoom level. The standard text size in a browser is usually 16 pixels, but a user can change this. Make sure your site follows this instead of forcing the user to zoom every time. Also, don't forget users with impaired color vision. Ensure there is something other than just color that distinguishes different elements, and that there is a clear contrast between text and background.

Forms and Modals

If there is one thing that creates accessibility problems more than anything else, it is different types of forms. In theory, it is quite simple to build accessible forms; there are plenty of input fields of various kinds in the HTML standard. The problem is that they don't always fit with other desired functionality or graphic design. Instead, smart features are built that hinder rather than help. – On credit cards, numbers are grouped in sets of four. It is not uncommon for an e-commerce site's input field to "help" by inserting a space after four characters. Pressing the backspace key to correct an error can then become completely impossible. Such mistakes are annoying for most people but can make the service completely unusable for those who need extra support.

Use standard functionality, and it will be easier for everyone who uses the service.

• Use the correct type of input field for the information requested.
• Help the user immediately when incorrect information is entered; don't wait until the form is to be submitted.
• Every input field should have a label; don't rely solely on placeholder.
• Group the form's fields into logical parts. Feel free to use fieldset and legend for different groups.

Modals are another common source of frustration. Information hidden in a modal can be difficult to find, and once the modal is opened, it can be quite tricky to close it again. Make sure it is clear in the code that a modal will open and that there is an easy-to-find close button in the modal (the Esc key should preferably close the modal). When the modal opens, the user's focus should be moved to the modal's first interactive element (preferably a close button), and when it closes, focus should return to where it was before the modal opened.

Keyboard

The entire site should be accessible by using only the keyboard. Jump between interactive elements with tab, make selections with space, and submit forms with enter. All of this is standard, and with correct HTML, the keyboard will work without problems.

To facilitate this, there are attributes like tabindex that can be used to change the order in which focus moves when the user presses tab (elements that would normally receive focus can also be ignored). Make sure not to trap keyboard users when modals open or similar. Do not override common keyboard shortcuts with custom functionality. Provide the option to turn off the site's own combinations. Remember that information displayed only on hover or click can be difficult for keyboard users to find.

ARIA Attributes

To facilitate screen readers and other assistive technologies, there are ARIA attributes for various HTML elements. ARIA attributes can be used as a complement to HTML code to make the page content clearer for the user. Icons and other purely visual elements can be ignored by screen readers by adding the attribute aria-hidden=”true”. Help texts and error messages can be highlighted with the attribute role=”alert”. Interactive icons can be made readable with the attribute aria-label=”Öppna meny”. However, it should be noted that ARIA attributes are complements that do not replace correct HTML code. For example, it is better to use <label> than to simply add aria-label to an input field. Incorrect use of ARIA attributes can create more problems than not having them at all, so feel free to use them, but only where they truly provide benefit.

Test Usability

There are many systems that can review a site and analyze the code to find possible accessibility problems. Perhaps it's not a bad idea to schedule a job to run on the site before an update goes live? The best way to test the site, however, is of course to try it yourself.

• Try to access all site functions using only the keyboard – Did it work?
• Navigate the site only in grayscale – Is everything that needs to be visible, visible?
• Start a screen reader and close your eyes – Do you understand what's happening on the site?

In summary, from a technical perspective, accessibility primarily means not unnecessarily building in difficulties. The standards and assistive technologies available today are developed with basic web technology in mind. If you follow the advice provided, your site will work excellently.