Accessibility Evaluation

About this project

The project aimed to analyze and evaluate the current state of various features within Sciex OS, focusing on accessibility, to create a prioritized list of key improvement areas.

Role:

UX Researcher

6 months

Background

Sciex formed a new User Experience department in 2018 the department only had one UX professional and sporadic contractor support. I joined the team in 2020 and found an opportunity to access and evaluate the current state of accessibility across various features within Sciex OS.

What was the problem?

The lack of a dedicated UX department has resulted in Sciex OS missing critical accessibility assessments and evaluations. This gap has hindered the identification of improvement opportunities and the demonstration of the business value of UX principles.

Objective

Conduct an accessibility evaluation of Sciex OS to identify gaps, enhance user experience, demonstrate business value, ensure compliance with standards, and prioritize key improvements.

Process & Journey

research

Business Need

Enhance Market Competitiveness: By improving accessibility, Sciex OS can attract a broader user base, including individuals with disabilities, thereby increasing market share and demonstrating corporate social responsibility. This can lead to higher customer satisfaction, loyalty, and potential revenue growth.

User Need

Inclusive User Experience: Users, especially those with disabilities, need an accessible and user-friendly interface that allows them to effectively interact with Sciex OS. Ensuring accessibility helps all users to have a seamless and equitable experience, enhancing their overall satisfaction and productivity.

purpose

Identify Accessibility Barriers: Detect and document existing accessibility issues within Sciex OS.
Improve User Experience: Enhance the usability and satisfaction for all users, including those with disabilities.
Ensure Compliance: Align Sciex OS with relevant accessibility standards and regulations.
Promote Inclusivity: Foster an inclusive environment by making the software accessible to a diverse user base.
Increase Market Reach: Expand the potential user base by making the product accessible to more people.
Demonstrate Business Value: Show the tangible benefits of accessibility improvements, such as increased user engagement and loyalty.
Prioritize Development Efforts: Provide a clear roadmap for addressing the most critical accessibility issues.
Enhance Brand Reputation: Position Sciex as a leader in accessibility and user experience.

We began by thoroughly examining global accessibility standards. To ensure our evaluation was comprehensive and up-to-date, we utilized resources from the World Wide Web Consortium (W3C) and the Web Accessibility Initiative (WAI).

Keyboard Accessibility

Requirements:

A (must have):

2.1.1 Functionality is operable through a keyboard interface
2.1.2 Don’t trap keyboard users

AAA (nice to have):

2.1.3 All functionality is operable through a keyboard interface (no exceptions)

Examples:

Have a few functions supported by the keyboard, e.g. tab to move between objects, Esc to close windows, Enter to apply, and arrow keys to move across the table.
But miss some keyboard functionality (e.g. Esc doesn’t always work), cannot use app without mouse.
Not consistent – may have or not the hot-keys, use different hot keys for similar actions.

Text Alternatives

Requirements:

A (must have):

1.1.1 Provide text alternatives for non-text conten

Examples:

Do have tooltips for some icons.
But no text explanation to graphs and charts.

Distinguishable

Requirements:

A (must have):

1.4.1 Use of Colour: presentation doesn’t solely relies on color

AA (should have):

1.4.10 Reflow: Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions
1.4.4 Resize Text: Text can be resized to 200% without loss of content or function

AAA (nice to have):

1.4.8 Visual presentation: Offer users a range of presentation options

Examples:

Use of color:

Do support colors with shapes.
But the green and red tones in the brand library are hard to distinguish for smaller images (e.g. Data Reviewer),
It may be hard to distinguish colors in Peak Viewer for overlayed graphs.

Reflow:

In some workspaces (e.g. Analytics, Batch) users may have large data tables and need to scroll in two dimensions.

Resize text:

Works good with Windows accessibility settings, but the graphs are not well visible (see the next slide)

Range of presentation options:

Have range for tiles (icons+ text), for Analytics (graphs support table data)
Not for graphs (only visual w/o text description)

Input Assitance

Requirements:

A (must have):

3.3.3 Error suggestion: Suggest fixes when users make errors

AAA (nice to have):

3.3.5 Help: Provide instructions and cues in context to help in form completion and submission
3.3.6 Error prevention: If the user can submit information, the submissions are reversible verified or confirmed

Examples:

Error suggestion:

Not often provide instructions to fix the problem, just mention the problem.
Explanation of the issue in the Event log is not always meaningful.

Help:

Have many instructions in Help, Help directs users to the current workspace.
But Help is not always in the proper context (e.g. for Tuning and Calibration), some users don’t know about the Help file, Help function is not ideally searchable.

Error prevention:

Do have validation for the majority of critical actions, don’t have validations for some Tuning actions.
Tend not to have ‘Undo’ actions.

Adaptable

Requirements:

AA (should have):

1.3.4 Orientation: Content does not restrict its view and operation to a single display orientation.

Examples:

User can move some windows to another screen (e.g. floating windows in MS Method, Peak Review).
But in many cases can only move windows within the main screen (e.g. in Analytics and Explorer).
Cannot work with several workspaces at the same time.
Cannot look at the Quick Help simultaneously with working in the SCIEX OS workspace.
Not always possible to quickly adjust a window per monitor size.
Default window size may be not optimal – too small or too large (e.g. larger than the available screen size).

Navigable

Requirements:

AA (should have):

2.4.6 Use clear headings and labels
2.4.7 Ensure keyboard focus is visible and clear

AAA (nice to have):

2.4.13 Area of the keyboard focus indicator should be well visible

Examples:

Use clear headings and labels:

Good overall but may be hard to match the label and the field (work in progress in IxD team).
Naming may be not consistent – e.g. compounds and components.

Keyboard focus is not always visible:

Good for tables and forms, but bad for navigation between different objects (e.g. when using a tab, object selection often is not visible).

Brand Library scroll bars are quite narrow – hard to click.

Readable

Requirements:

AAA (nice to have):

3.1.3 Unusual Words: Explain any ‘strange’ words, including idioms and jargon
indicator should be well visible

Examples:

Have many idioms and jargon that may be not clear for users, may not explain them or explain in the Help file outside of context.
May use an abbreviation instead of the full word.

Input Modalities

Requirements:

A (must have):

2.5.1 Pointer Gestures: All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture.
2.5.2 Pointer Cancellation: For functionality that can be operated using a single pointer, at least one of the following is true: No Down-Event; Abort or Undo; Up Reversal.

AA (should have):

2.5.7 Dragging Movements: All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging.
2.5.8 Target Size (Minimum): The size of the target for pointer inputs is at least 24 by 24 CSS pixels.

AAA (nice to have):

2.5.5 Target Size (Enhanced): The size of the target for pointer inputs is at least 44 by 44 CSS pixels.

Examples:

Pointer gestures and dragging movements: user cannot zoom w/o mouse.
Pointer Cancellation: don’t have undo for many areas.
Target size: sometimes it is hard to point on icons which are too small (e.g. in Explorer), Brand Library scroll bars are narrow.

What works well?

Adaptable – pages have a logical structure and meaningful order of content, windows may be adjusted according to the screen size, validation for different type of input.
Distinguishable – good contrast between the content and the background, colors are supported with shapes, has tooltips if the text is too long.
Navigable – logical order and helpful page titles, break up content with headings, ability to understand the current ‘location’/path at the moment, ability to zoom in graphs, ability to scroll to see the content outside of the page, ability to resize the windows and customize the views.
Predictable – consistent use of design elements like icons, buttons, windows, access to help, presence of submit buttons.
Assisted input – clearly identify input errors, provide instructions and propagate user input to other windows.
Enough time for operations, time limits are user adjustable, no time limits for using the app, no interruptions for content consumption time, provide user controls to start and stop operations.

What can be improved?

Keyboard accessibility
Text alternatives for non-text content (graphs and charts)
Input assistance – error suggestion, help and error prevention
Small elements like text, icons and scroll bars
Use of Color – accessibility for users with visual deficiency
Adaptability for different screen orientation and multiple screens
Consistency of terms

learning

Conducting an accessibility evaluation as a UX Researcher offers insights into user diversity and global standards. It enhances collaboration, practical testing skills, and prioritization strategies. I also learnt the importance of continuous improvement, educational outreach, and the business impact of accessibility.

Other Projects:

Let’s connect

Get in touch for opportunities or just to say hi!👋