Follow the process around accessibility outlined on the SAP Accessibility Guidelines for Designers. Use the Design checklists to create specifications and provide design specification for developers using annotation elements from the the SAP Accessibility Annotations library.

Some annotations to inform accessibility on design

Why do I need to create accessibility specification?

When providing mock-ups with meaningful notes, UI Developers are able to implement the inclusive experience as per the recommendation of a User Experience Designers.

Key annotation will explain how users should navigate and interact with UI elements using keyboard and screen reader tools. It can also explain decisions that affect journeys to support user orientation, wayfinding, error prevention and error handling, change in context, among other considerations that are likely to affect users with cognitive disabilities.

SuccessFactors puts the user's needs front and center starting in the design phase resulting in a product that provides inclusive experiences. A much better reason compared to accessibility violation avoidance, less Jira tickets or stay away form accessibility lawsuits.

How to create specification?

Checklists remind designers about important considerations to fulfill accessibility

A SFSF template gives you a direction to create a design specification for accessibility.

Here a guideline to help designers annotate mockups for corrrect implemenation of Assessibility

• Introduction
• Component Handling
• Screen Reading
• Focus Order & Keyboard
• Complementary

We have listed a couple of Best Practice examples for A11y Annotations:

There are two ways to go about annotations. You have to identify annotations that contribute to the and of the , but also provide support for the user to work on a like a simple that includes or .

Identify your annotation strategy and repeat common patterns making it simple and focused in two aspects:

• Page layout template (Page List, Page Details and Page Forms).
• Core Components and UI elements that can be re-used safely across the application.

Another consideration is if the design request requires a or only to an existing flow by adding or replacing UI elements on an existing page.

It means that the page does not exist in the product inventory of pages within the SuccessFactors solution. In this case the design must be annotated on the page level and UI elements and flow levels.

If you are only enhancing what already exists in a page, review the previous list before. The annotation of an exiting page should be available for consultation.

:

• Component name, Floorplan name, Reflow for Text Resize, Text Spacing, Responsive and Orientation, Focus order sequence, Skipping groups, Initial focus, Screen reading sequence, Landmarks, Headings, Page Title, Wayfinding, Error Prevention and Error handling.

:

• Component name, Role and Properties, Predictable Context, Speech Output, Color Contrast and Target Size if custom components, Sensory Concept, Focus order sequence, Skipping group, Initial Focus, Shortcuts for common actions, Messages, Screen Reading sequence, Headings, Descriptions, Tooltips, Time Limits & Refresh, Error Prevention and Error Handling, Accessible Alternatives for charts and graphs.

WEB, Mobile, Tablet and Native Mobile

Accessibility Annotation for web also applies to mobile and tablets. There are 3 exceptions to keep in mind when annotating designs for mobile:

• Landmarks;
• Headings;
• Tooltips.

Landmarks do not apply to native apps. Headings are accounted on screen reading navigation but do not consider heading level hierarchy. Tooltips, although it could be implemented for Android using a lon tab, it cannot be implemented for iOS.