- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
07-25-2023 11:04 AM - edited 07-25-2023 11:41 AM
Recently, someone asked me about the Accessibility toggle in the Service Portal. At first, when I tried it out, I wasn't sure exactly what changed since the Service Portal's experience seemed similar whether accessibility was on or off. However, I found that enabling accessibility brings some small yet important design improvements to make the Service Portal more user-friendly for everyone.
When accessibility is enabled:
1. User Preference called "glide.ui.accessibility" is created that "Enables universal access, which increases accessibility when using a screen reader or keyboard".
This will make it easier for everyone to navigate the Service Portal.
2. Portal Notifications, like those created from "addMessage", "addInfoMessage", or "addErrorMessage" remain on the screen until the user clicks the "X" button.
The time it takes for notifications to disappear automatically in the Service Portal is determined by the "glide.service-portal.notification_timeout.seconds" System Property, which is set to 5 seconds by default.
When accessibility is enabled, the notifications in the Service Portal will stay visible on the screen, regardless of the value set of this System Property, until they are manually closed with the "X" button. This feature ensures that users who may require more time to read and process notifications can do so without any time constraints.
Here's a demo showing the difference.
Notice how in the accessible version that the "X" button has a focus styling box around it too!
Something to note is if you have any sort of Catalog Client Script that clears notification messages with "g_form.clearMessages()", this does override the accessibility setting and will remove the notifications from the screen without any user interaction.
3. Contrast theme is applied.
Out-of-box widgets such as "Data Table (widget-data-table)" and "Icon Link" add a high contrast CSS class if accessibility is enabled. This helps improve visibility and readability of these elements.
// Icon Link Widget
// Body HTML template
<div class="iconlink" ng-class="{'high-contrast': accessibilityModeEnabled}">
...
</div>
// Client Controller
$scope.accessibilityModeEnabled = spAriaUtil.isAccessibilityEnabled();
Here's a side-by-side comparison of the "Icon Link" widget. Look at how the widget is styled differently depending on the accessibility setting.
Without accessibility, icon backgrounds and heading text use lighter colors.
With accessibility, focus styling uses underlines for text and darker colors for icon backgrounds and heading text.
This and more styling comes from the "sp-theme-stock-high-contrast.css" Style Sheet that's included in the "La Jolla" theme (/nav_to.do?uri=sp_css.do?sys_id=27b1bbc277002300a6e592718a106137).
Hopefully this helped you learn more about the accessibility setting in the Service Portal, and I encourage you to enable it if you haven't already done so. Thanks for reading!
- 5,834 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
This is amazing article @Jesalyn S 👏
This Accessibility feature emphasizes inclusiveness and equal access to everyone!
Kind Regards,
Ravi Chandra.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
I do appreciate this article, but I have accessibility turned off for me, but the SP is still applying all of the accessibility things to the elements on the page.
In addition to jumping to the X on modals. That last is really annoying because it always shows a tooltip, too. I don't want to get rid of tooltips, but I also want to opt into them.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Which, I might add, is super annoying because they slapped `!important` all over their accessibility styles.