Accessibility in technical implementation

What are the accessibility criteria for technical implementation?

The matters listed on this page are success criteria for accessibility pertaining to the technology of the publication that must be taken into account when assessing the implementation of accessibility. The technical requirements are based on the Web Content Accessibility Guidelines (WCAG) issued by the World Wide Web Consortium (W3C).

Those in charge of the technology of the pages are responsible for ensuring that the technology supports accessibility and makes it possible for users of the website and content producers to publish contents in an accessible form. Technology covers all the features the implementation of which is determined in the source code of the system and that users cannot change. Examples of such features include the possibility of adding alt texts to images and indicating the language of the website in the <html> root element with the ‘lang’ attribute.

The entirety of the technical implementation of the website should preferably use an HTML element suitable for each purpose, provided that one exists. The contents of the page should always be implemented by using standard HTML marking. The recommended HTML language level is 5 (HTML5), and as such, the implementation should use HTML5-level semantic elements.

For example: a button must be implemented with the HTML ‘button’ element, not a custom div element with CSS formatting and JavaScript-based functions. Standard elements automatically provide the correct functionality and are for the most part accessible to assistive technologies without any additional settings.

The features listed below are such that any notifications received regarding them in accessibility inspections (audits or automatic inspections) continue to require manual checking, after which they must be forwarded to be remedied by the party responsible for the technology of the website.

Page structure and correct use of elements (semantics)

  • page <title>
  • indicating the language of the page with the ‘lang’ attribute
  • indicating the language of a section of the page when there are sections on the page in different languages (‘lang’ attribute)
  • correct use of headings (partly the responsibility of content producers)
  • ‘landmark’ elements (forming the page structure by using these is recommended)
  • <header>, <nav>, <main>, <footer> or the equivalent ARIA codes role=“banner”, role=“navigation”, role=“main”, role=“contentinfo” – lists
  • tables
  • ‘iframe’ embeddings – HTML validity

Links, navigation and use of the website

  • “Jump links”, links straight to navigation, the main content and the site map immediately at the start of the <body>-element.
  • Links:
    • always include a machine-readable heading (label) and a clear indication of where the link leads
    • unified site navigation on all pages.
  • Internal navigation on the page:
    • content order / focus order
    • logical and sound transition order between elements
    • no positive ‘tabindex’ values (greater than zero)
    • readily discernible visual highlighting of the active element.
  • All sections of the website can be used without a mouse by only using a keyboard.
  • Do all elements conform to the general and expected functionality?
  • Activating an element (focus) does not cause the content to change or a transfer to new content.

Images and visuality

  • Alt texts can be added to images.
  • Decorative images either have suitable alt texts or are hidden from screen readers.
  • The colours and contrasts meet the requirements set for them.
  • The text styles are readable.
  • Changing the size of the page meets the Reflow and Zoom success criteria for page content positioning.
  • Adaptive contents, position detection.

Multimedia, animations, motion

  • Audio files:
    • the user has access to the necessary playback and volume controls
    • the volume must be adjustable separately from the general system volume.
  • Video files:
    • the user has access to the necessary playback and volume controls
    • captions can be added to video files, preferably with the ‘closed captions’ technique in which the captions are not hardcoded into the video, but provided as a separate machine-readable text.
  • Animations:
    • no distracting and intense motion effects
    • no intense and contrasting colours
    • no rapidly blinking elements (more than 3 times per second).

Timed functions

  • Users must have enough time for carrying out the function.
  • The user is notified when the time is running out and provided with an easy way to request more time.

User input: forms

  • Device-independent input: the user must be able to change the input method (mouse, keyboard, touchscreen) in the middle of carrying out a function.
  • All form fields have a visible and program-readable heading (label).
  • The input field types of the form always correspond with the content to be entered.
  • Input type in accordance with the content, allowing devices with a touchscreen to select the correct “on-screen keyboard”.
  • All forms feature sufficient and clear user instructions.
  • Form validation (input verification):
    • faulty inputs trigger a clear notification and instructions for remedying the issue
    • when a form is submitted successfully, the user is provided with a visible and permanent notification
    • the aforementioned notifications must also be provided in a format detected by screen readers.
  • Avoid CAPTCHA or provide an accessible version of the verification process.

Custom controls

  • Do all custom controls, script components, etc. have appropriate ARIA roles and name values to indicate the purpose of the control?