Accessibility - Dashboard Pages
|
Accessibility criteria |
widget settings: plan-status, quality-score, evaluation calibration, forms calibration, kpi trend, coaching |
widgets: cxone agent contact view |
|---|---|---|
|
Text Alternatives and Captions Make visuals understandable for all Images, icons, and media must have clear text alternatives like alt text, labels, or transcripts. Example: Added alt text to icons on the dashboard and ensured that icons without meaning are marked decorative. |
Yes |
Yes |
|
Visual Design: Color and Contrast Make content easy to read and see Text and visual elements need enough contrast from the background, and pages must work well with 200% zoom. Example: Increased contrast between text and buttons; tested main pages on 200% zoom to ensure nothing is cut off. |
Yes |
Yes |
|
Keyboard Navigation and Focus Make sure the product works without a mouse Users should reach elements by keyboard. Focus (like outlines) must always be visible and not hidden behind headers. Example: Tabbing through the header presents a new button called “skip to main content”, dropdown menus open on keyboard. |
Yes |
Yes |
|
Assistive Tech Support (JAWS, Voice, etc.) Work well with screen readers and voice tools Elements must have correct labels and roles so assistive tools (like JAWS or Dragon) can read or activate them. Example: Added accessible names to buttons so Dragon can trigger “Send”; tested screen reader flow for announcements and buttons. |
Yes |
Yes |
|
Page Navigation Keep movement clear and predictable Menus and links should be in the same spot on every page, keyboard-friendly, and clearly labeled with logic navigation between components. Example: User Keyboard Navigation guide is functional across elements. All menus can be accessed using the Tab key. |
Yes |
Yes |
|
Forms and Error Messages Make input clear and fixable Fields have a label, and mistakes should be showing clearly. Example: “Skill Name field is required” now shows below the field. Focus changes to notification. |
Yes |
Yes |
|
Status Messages and Alerts Announce changes for assistive tools When something changes (like “saved” or “error”), tools like screen readers should hear it. Example: Success messages use ARIA live region — JAWS reads “Saved successfully”. |
Y |
Y |
|
Accessibility criteria |
Add Left/right navigation arrows on lower resolutions on widget panel |
|---|---|
|
Text Alternatives and Captions Make visuals understandable for all Images, icons, and media must have clear text alternatives like alt text, labels, or transcripts. Example: Added alt text to icons on the dashboard and ensured that icons without meaning are marked decorative. |
Y Left/right arrow icons include descriptive alt text (e.g., 'Navigate left', 'Navigate right'). |
|
Visual Design: Color and Contrast Make content easy to read and see Text and visual elements need enough contrast from the background, and pages must work well with 200% zoom. Example: Increased contrast between text and buttons; tested main pages on 200% zoom to ensure nothing is cut off. |
Y Arrow navigation controls meet WCAG 2.2 contrast requirements against widget panel background. |
|
Keyboard Navigation and Focus Make sure the product works without a mouse Users should reach elements by keyboard. Focus (like outlines) must always be visible and not hidden behind headers. Example: Tabbing through the header presents a new button called “skip to main content”, dropdown menus open on keyboard. |
Y Arrow navigation is keyboard operable; users can tab to arrows and activate with Enter/Space. |
|
Assistive Tech Support (JAWS, Voice, etc.) Work well with screen readers and voice tools Elements must have correct labels and roles so assistive tools (like JAWS or Dragon) can read or activate them. Example: Added accessible names to buttons so Dragon can trigger “Send”; tested screen reader flow for announcements and buttons. |
Y Navigation arrows include ARIA labels and role='button'; panel scroll position announced. |
|
Page Navigation Keep movement clear and predictable Menus and links should be in the same spot on every page, keyboard-friendly, and clearly labeled with logic navigation between components. Example: User Keyboard Navigation guide is functional across elements. All menus can be accessed using the Tab key. |
Y Widget panel navigation area properly structured as a navigation landmark. |
|
Forms and Error Messages Make input clear and fixable Fields have a label, and mistakes should be showing clearly. Example: “Skill Name field is required” now shows below the field. Focus changes to notification. |
N No form elements in navigation arrows feature. |
|
Status Messages and Alerts Announce changes for assistive tools When something changes (like “saved” or “error”), tools like screen readers should hear it. Example: Success messages use ARIA live region — JAWS reads “Saved successfully”. |
Y Panel scroll position and visible widget changes announced to assistive technology. |
|
Accessibility criteria |
Zoom in support to domain names in dashboard |
|---|---|
|
Text Alternatives and Captions Make visuals understandable for all Images, icons, and media must have clear text alternatives like alt text, labels, or transcripts. Example: Added alt text to icons on the dashboard and ensured that icons without meaning are marked decorative. |
Y Domain name icons and visual elements include descriptive alt text. |
|
Visual Design: Color and Contrast Make content easy to read and see Text and visual elements need enough contrast from the background, and pages must work well with 200% zoom. Example: Increased contrast between text and buttons; tested main pages on 200% zoom to ensure nothing is cut off. |
Y Domain name text and UI elements maintain WCAG 2.2 contrast compliance at 200% zoom. |
|
Keyboard Navigation and Focus Make sure the product works without a mouse Users should reach elements by keyboard. Focus (like outlines) must always be visible and not hidden behind headers. Example: Tabbing through the header presents a new button called “skip to main content”, dropdown menus open on keyboard. |
Y Add Widget domain selection remains fully keyboard navigable at 200% zoom. |
|
Assistive Tech Support (JAWS, Voice, etc.) Work well with screen readers and voice tools Elements must have correct labels and roles so assistive tools (like JAWS or Dragon) can read or activate them. Example: Added accessible names to buttons so Dragon can trigger “Send”; tested screen reader flow for announcements and buttons. |
Y Domain list items and selection controls properly labeled with ARIA at all zoom levels. |
|
Page Navigation Keep movement clear and predictable Menus and links should be in the same spot on every page, keyboard-friendly, and clearly labeled with logic navigation between components. Example: User Keyboard Navigation guide is functional across elements. All menus can be accessed using the Tab key. |
Y Domain section maintains proper heading and landmark structure during zoom reflow. |
|
Forms and Error Messages Make input clear and fixable Fields have a label, and mistakes should be showing clearly. Example: “Skill Name field is required” now shows below the field. Focus changes to notification. |
Y Domain search/filter inputs properly labeled and accessible at 200% zoom. |
|
Status Messages and Alerts Announce changes for assistive tools When something changes (like “saved” or “error”), tools like screen readers should hear it. Example: Success messages use ARIA live region — JAWS reads “Saved successfully”. |
Y Domain selection changes and list updates announced via ARIA live regions. |
|
Accessibility criteria |
dashboard (manage dashboard, header, modal popups, webapps) |
reports (my reports, prebuilt reports, report modal popups) |
Widgets & charts (widget settings, grids, chartjs, highcharts, widget container, queue counter) |
|---|---|---|---|
|
Text Alternatives and Captions Make visuals understandable for all Images, icons, and media must have clear text alternatives like alt text, labels, or transcripts. Example: Added alt text to icons on the dashboard and ensured that icons without meaning are marked decorative. |
Y Added alt text to all dashboard icons and images. |
Y Alt text added for report page icons. |
Y Alt text added to chart elements and widget icons. |
|
Visual Design: Color and Contrast Make content easy to read and see Text and visual elements need enough contrast from the background, and pages must work well with 200% zoom. Example: Increased contrast between text and buttons; tested main pages on 200% zoom to ensure nothing is cut off. |
Y Increased contrast in dashboard pages. Tested at 200% zoom. |
Y Contrast improvements in report pages and modals. |
Y Color contrast improved in charts and widget settings. |
|
Keyboard Navigation and Focus Make sure the product works without a mouse Users should reach elements by keyboard. Focus (like outlines) must always be visible and not hidden behind headers. Example: Tabbing through the header presents a new button called “skip to main content”, dropdown menus open on keyboard. |
Y Keyboard navigation enabled. Skip-to-main-content added (DASH-AMP1). Keyboard operability ensured (DASH-AMP13). |
Y Keyboard navigation for report pages and modals. |
Y Keyboard navigation for widget settings, grids, charts. |
|
Assistive Tech Support (JAWS, Voice, etc.) Work well with screen readers and voice tools Elements must have correct labels and roles so assistive tools (like JAWS or Dragon) can read or activate them. Example: Added accessible names to buttons so Dragon can trigger “Send”; tested screen reader flow for announcements and buttons. |
Y ARIA labels and roles added (DASH-AMP6, DASH-AMP7). |
Y ARIA attributes added to report controls. |
Y ARIA labels for charts, widgets, grids. |
|
Page Navigation Keep movement clear and predictable Menus and links should be in the same spot on every page, keyboard-friendly, and clearly labeled with logic navigation between components. Example: User Keyboard Navigation guide is functional across elements. All menus can be accessed using the Tab key. |
Y Skip navigation (DASH-AMP1). Meaningful frame titles (DASH-AMP20). |
Y Consistent report page navigation. |
Y Logical tab order in widget containers. |
|
Forms and Error Messages Make input clear and fixable Fields have a label, and mistakes should be showing clearly. Example: “Skill Name field is required” now shows below the field. Focus changes to notification. |
Y Form field labels and error messages added. |
Y Report modal forms properly labeled. |
Y Widget settings forms with validation. |
|
Status Messages and Alerts Announce changes for assistive tools When something changes (like “saved” or “error”), tools like screen readers should hear it. Example: Success messages use ARIA live region — JAWS reads “Saved successfully”. |
Y ARIA live regions for status messages. |
Y Status announcements for report operations. |
Y Widget status messages use ARIA live regions. |