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 nicely summarized at DIGG. However, we recommend that you also review the updates 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 Technologies and Standards

For people who need support, there are both built-in assistive technologies in operating systems and web 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 within a <nav> element. Ensure 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, a text version of the content should be available 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 default text size in a web browser is usually 16 pixels, but a user can change this. Then ensure that your site adheres to this instead of forcing the user to zoom every time. Also, do not 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'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 many types of input fields in the HTML standard. The problem is that they don't always align with other desired functionality or graphic design. Instead, clever features are built that hinder rather than help. – On credit cards, the numbers are grouped in sets of four. 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 render 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; do not wait until the form is submitted.
• Each input field should have a label; do not 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. 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 shifted 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 function without issues.

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). Ensure that keyboard users are not trapped when modals open or similar situations. Do not override common keyboard shortcuts with custom functionality. Provide the option to disable the site's own shortcuts. 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 aria-hidden=”true” attribute. Help texts and error messages can be highlighted with the role=”alert” attribute. Interactive icons can be made readable with the aria-label=”Öppna meny” attribute. 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 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 truly provide benefit.

Test Usability

There are many systems that can review a site and analyze the code to find possible accessibility issues. 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 to try it yourself.

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

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