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 is likely to 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 current web standards. If the HTML code is correct, it will be 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 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 an 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. In that case, make sure your site follows this instead of forcing the user to zoom every time. Also, don't forget users with impaired color vision. Make sure 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's one thing that creates accessibility problems more than anything else, it's different types of forms. In theory, building accessible forms is quite simple; there are numerous 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 instead of help. – On credit cards, numbers are grouped into fours. It's 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 using the service.

• Use the correct type of input field for the requested information.
• Help the user immediately when incorrect information is entered; don't wait until the form is 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 open, it can be quite tricky to close it again. Ensure that 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 ideally 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 only using 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, attributes like tabindex can be used to change the order in which focus shifts 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 combinations with custom functionality. Provide an option to turn off the site's own combinations.
• Remember that information only displayed 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 different 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 become readable with the attribute aria-label="Öppna meny". It should be pointed out, however, that ARIA attributes are complements that do not replace correct HTML code. For example, it is better to use <label> than to simply put aria-label on 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 genuinely provide benefit.

Test Usability

There are numerous systems that can go through a site and analyze the code to find potential accessibility problems. Perhaps it's not a bad idea to schedule a job that runs on the site before an update goes live? The best way to test the site, however, is to try it yourself.

• Try to access all of the site's 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 is primarily about 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 function excellently.