Accesssibility

Owned by Bojhan Somers
Last updated: Nov 05, 2023
3 min read

We believe access should aim to be WCAG 2.2 AA compliant.

The guideline we follow can be found at Web Content Accessibility Guidelines (WCAG) 2.2

In Seamless Access it is the standard we pursue, and it is the standard that is considered a community practice across many organisations.

We suggest to focus on at least these 4 area’s:

  • Keyboard friendly; allowing users to navigate using their keyboard (logical tab orders, focus on dialogs).

  • Zoom friendly; allowing users with impaired vision to be able to magnify content.

  • Appropriate contrast; ensuring a contrast ratio of 4.5:1 is applied to all text, and 3:1 to all headers.

  • Screen reader friendly; allowing users with assistive technology to use Seamless Access, where all visual cues are also announced and additional guidance is provided.

Access in the scientific domain sees a wide variety of practices, often not providing a unified experience for those who run into impairments. Creating a disjointed experience or entirely inaccessible experience, limiting users their access to knowledge.

How to evaluate

Evaluating accessibility is the best way to assess if a tool is accessible, due to the nature of these guidelines many systems that claim to be accessible - are in fact not.

Self evaluate: We strongly suggest to start each accessibility evaluation by using the tools yourself. This allows you to understand minute details and experience the many roadblocks that can stand in the way of access.

  • Experience inability to use mouse, by navigating only using tab and enter.

  • Experience inability to see by enabling a Screen reader (available in Windows and MacOS)

  • Experience poor eye-sight by zooming in the browser (MacOS: CMD +, Windows: CTRL +)

  • Check contrast at Web AIM

Semantic evaluation: W3C offers a large set of tools, found in its Web Accessibility Evaluation Tools List which allows you to run checkers against the code that is produced by systems. This front-end code is used to render the website, running checkers against this allow you to spot problems early on.

Expert evaluation: Experts are available at universities or supporting organisations. Expert evaluations are advised in situations where Semantic tools cannot be run, and/or the richness of the system makes it hard to evaluate.

User evaluation: Users with impairments can assist you in evaluating if your system, keep in mind that several users should be evaluated as experiences vary and disabilities also range greatly. In addition to finding accessibility problems, issues found can also often affect those without disabilities.

Checklist

We offer the following checklist to evaluate if the system your using or intending to deploy is acessible.

Button

Can the access button be navigated to by keyboard alone?
Can the access button be found quickly (e.g. directly after abstract)?
Is the access button announced when your using a screen reader?
Does the access button meet high contrast requirements?

Searching for institution(s)

Is there an announcement there is a search form when using your screen reader?
Is there an announcement a user can put an institution in (with helpful explanation) when using a screen reader?
Can the search input form be navigated to by keyboard alone?
Is there an announcement that search results are being loaded when using a screen reader?
Does the input form meet high contrast requirements?

Resulting list of institution(s)

Does the result list meet high contrast requirements?
Is there an announcement results are found and how many when using your screen reader?
Is there an announcement which result is selected when using your screen reader?
Can the result list be navigated down and up using only your keyboard?
Is there a indicator which option is selected relying on not just color?
Is the indicator meeting high contrast requirements?

 

 

Â