Overall Rating by Theme
1
Accessibility
Compliance
Scale
0 — Inadequate
1 — Minimal ← Current
2 — Good
3 — Excellent
Finding Distribution
Findings by Theme (stacked by severity)
Accessibility — Keyboard & Focus
Visual Design & Typography
Detailed Findings
15 findings across 5 themes. Items marked ⚠ require live / assistive-technology testing to confirm.
Theme 1 — Modal / Dialog Pattern
Screen
Create PolicyEdit Policy
Standard
Carbon Dialog Pattern — Anatomy of a dialog: "The close × icon will close the dialog without submitting any data." Every modal must have a dismiss path independent of the action buttons. WCAG 2.1 SC 2.1.1 (Keyboard).
Why it matters
Users who open the modal by mistake have no standard escape path. Keyboard users must Tab to "Cancel" with no guaranteed focus order. Screen readers expect an accessible close button for the dialog role.
Recommendation
Add a Carbon Modal close button (×) in the top-right corner. Ensure it is the first focusable element or clearly annotated as the focus target on open for passive / transactional modals per Carbon guidance.
Confidence
High — visible in static screens
⚠ Needs human validation: Verify whether Escape key triggers dismissal in the live product. If yes, document it and still add the visible × button for discoverability.
Screen
Edit Policy — Rules expanded
Standard
Carbon Modal — large complex content should scroll inside the modal container; the footer action buttons must remain visible at all times (sticky footer pattern). IBM Experience Standards — Learnability / Error prevention.
Why it matters
With 17 rules and the Rules section collapsed initially, once expanded the modal content (rules table + action buttons) may be hidden below the fold at common viewport sizes. Users on smaller screens may not find Save / OK.
Recommendation
Use Carbon's transactional modal with a sticky footer. Set max-height on the body area and enable internal scroll. Alternatively, consider a full-page form pattern instead of a modal for complex multi-section policies.
Confidence
Medium — needs live viewport testing
⚠ Needs human validation: Test at 768 × 1024 and 1280 × 800 viewport sizes with the Rules section expanded.
Standard
Carbon Dialog Pattern: "Avoid nested modal dialogs." Stacked modals create unpredictable focus trap behaviour and break browser back-navigation expectations.
Why it matters
The Roles dialog opens on top of the Create Policy modal (a third layer above the page). This creates a three-layer stacking context. AT users lose track of context; focus may not correctly return to the trigger element on close.
Recommendation
Replace the Roles nested modal with an inline multi-select dropdown (Carbon MultiSelect), a side panel, or a popover. If a separate dialog is required, close the parent modal first and reopen after roles are selected.
Confidence
High — visible in static screens
⚠ Needs human validation: Screen reader testing to confirm focus return to "Roles" button after dialog closes.
Standard
Carbon Modal style: "Modal labels and headings should be set in sentence case." The title "policy" should be capitalised as "Policy" or be more descriptive, e.g. "Assign roles for this policy".
Why it matters
Ambiguous heading gives no task context. Users landing by screen reader hear "policy dialog" with no indication of what action they are performing.
Recommendation
Change title to "Assign roles" or "Policy roles". Ensure the aria-label on the dialog container matches the visible heading.
Confidence
High — visible in static screens
⚠ Needs human validation: Check ARIA aria-labelledby / aria-label on the dialog element in dev tools.
Theme 2 — Accessibility — Keyboard & Focus
Screen
Create PolicyEdit Policy
Standard
Carbon Modal Accessibility: "For transactional dialogs, designers should annotate that the first input field should receive focus." WCAG 2.1 SC 2.4.3 (Focus Order).
Why it matters
Without a designated focus target, browser/AT behaviour is inconsistent. Keyboard users may start focus outside the modal or at an unexpected element, causing disorientation.
Recommendation
Annotate in design specs that the "Name" text input should receive focus when Create Policy modal opens. Verify that the modal container has role="dialog" and aria-modal="true", and that focus is trapped within it.
Confidence
Medium — requires keyboard testing
⚠ Needs live keyboard testing: Tab into modal and verify focus lands on "Name" input. Test focus trap — Tab from last focusable element should wrap back to first.
Screen
Edit Policy — Rules expanded
Standard
Carbon Toggle Accessibility: toggle must have an associated label. The column header "Continue to next rule" serves as a visual label only — each individual toggle must have its own programmatic accessible name. WCAG 4.1.2 (Name, Role, Value).
Why it matters
Screen readers may announce each toggle only as "switch, on/off" with no rule context. A user cannot determine which rule's continuation behaviour they are toggling.
Recommendation
Each toggle should have an aria-label or aria-labelledby that includes the rule name, e.g. "Continue to next rule — Cross-Site Scripting (XSS)". Apply visually-hidden text if UI space is a constraint.
Confidence
High — standard requirement
⚠ Needs screen reader testing: VoiceOver / NVDA to confirm what is announced when toggle receives focus.
Screen
Edit Policy — Rules expanded
Standard
Carbon Data Table Accessibility — checkboxes in selectable rows must each have a programmatic label identifying the row content. WCAG 1.3.1 (Info and Relationships), 4.1.2.
Why it matters
Without per-row labels, a screen reader user hears "checkbox, unchecked" for every row without knowing which rule is being selected.
Recommendation
Use Carbon's built-in DataTable selectable rows which automatically link checkbox labels to row content via aria-label="Select row [Rule name]". Validate in code that this pattern is implemented.
Confidence
Medium — requires code inspection
⚠ Needs screen reader testing and code review to verify aria-label on each checkbox.
Screen
Edit Policy — Rules table
Standard
IBM Experience Standards — Usability / task completion. Carbon Data Table: long content should use expandable rows or overflow tooltips, not silent truncation without a tooltip or expand control.
Why it matters
The Criteria column contains complex regex patterns that are critical for a security admin validating a rule. Truncation without a reveal mechanism means users cannot confirm rule logic without opening a separate edit view.
Recommendation
Add expandable rows in the rules table, or a tooltip / popover on hover/focus to reveal full criteria text. Alternatively, make rows clickable to show a detail panel.
Confidence
High — visible in static screens
⚠ Needs live testing: Check whether a hover tooltip exists on truncated cells that is not visible in screenshots.
Theme 3 — Toolbar & Icon-Only Actions
Screen
Security Policies list
Standard
Carbon Button Accessibility: "When buttons do not have a persistently displayed label, they must be annotated with a label that will be exposed on hover or focus." The toolbar shows + ✏ ⧉ – ⟳ ⊘ ↓ icons with no visible text. WCAG 2.4.6 (Headings and Labels), 1.1.1.
Why it matters
Icon meaning is not universally understood across roles (e.g. the circular arrow could mean "refresh" or "reinstall"). Users with cognitive disabilities and new users cannot determine action intent. AT users need aria-label on each button.
Recommendation
Use Carbon icon-only buttons with tooltip aria-label annotations. Consider adding visible text labels for primary actions (Create, Edit, Delete) using Carbon's Button with icon. Confirm tooltips appear on focus for keyboard users, not only on mouse hover.
Confidence
Medium — tooltip may exist on hover
⚠ Needs keyboard testing: Tab to each toolbar icon and verify tooltip is announced. Verify aria-label values in DOM.
Screen
Security Policies list — Install button
Standard
Carbon Overflow Menu / Split Button — the secondary action chevron must have its own aria-label (e.g. "Install options") separate from the primary button label. WCAG 4.1.2.
Why it matters
Two focusable elements side by side with the same or no label creates confusion for keyboard and AT users who cannot distinguish the primary Install action from the dropdown toggle.
Recommendation
Use Carbon's ComboButton or ensure the chevron button has aria-label="Open install options" and is visually distinct with a separator.
Confidence
Medium — requires code inspection
⚠ Needs screen reader testing and DOM inspection of the Install button's chevron element.
Screen
All screens — global header
Standard
WCAG 1.1.1 (Non-text content) — badge counts conveyed visually must also be conveyed programmatically via aria-label.
Why it matters
A screen reader user navigating to the notification icon should hear "Notifications, 315 unread" not just "button" or the icon name.
Recommendation
Ensure the notification icon button has a dynamic aria-label="315 notifications" or equivalent live region update.
Confidence
Medium — requires code inspection
⚠ Needs screen reader testing.
Theme 4 — Form & Input Design
Screen
Create PolicyEdit Policy
Standard
Carbon Form Accessibility: "Traditionally, a legend at the start of a form identifies the symbol (often an asterisk) used for required fields… an instruction should precede a form." Type * appears on "Type" and "Name" labels but there is no legend explaining the asterisk. WCAG 3.3.2 (Labels or Instructions).
Why it matters
New users and those with cognitive disabilities may not understand that * denotes a required field without an explicit legend. This is especially relevant in a complex security product context.
Recommendation
Add a helper line above the form fields: "Fields marked with * are required." Follow Carbon's form guidance on required field identification.
Confidence
High — visible in static screens
⚠ Needs validation: Confirm whether * is exposed to AT as "required" via aria-required="true" on each input — that partially mitigates the visual legend issue but does not replace it.
Screen
Create PolicyEdit Policy
Standard
Carbon ComboBox / Select — uses a single chevron affordance. A pencil icon inside a text input is not a Carbon pattern and creates ambiguity about field behaviour (is it read-only? editable? does pencil open edit mode?). Carbon Design System component deviation.
Why it matters
Users may be confused about whether the field is directly editable, a dropdown, or a hybrid. The two icon buttons at the right edge of the input create two separate tab stops whose purpose is unclear without labels.
Recommendation
Replace with a Carbon ComboBox that allows free-text entry and selection from existing categories. If inline edit is required, use Carbon's InlineEdit pattern. Remove the custom pencil icon from within the input.
Confidence
High — visible in static screens
⚠ Needs product context: Clarify whether the pencil triggers an edit mode and whether the category list is fixed or free-text.
Theme 5 — Visual Design & Typography
Screen
Create PolicyEdit Policy
Standard
Carbon Modal style: Heading should use $heading-03 — 20px / 1.25rem, Regular 400. The visible modal title "Create New Policy" / "Edit Policy: Basic Data Security Policy" appears heavier and larger than the Carbon token spec, suggesting a custom style override is applied.
Why it matters
Inconsistent type hierarchy between modals and the rest of the product undermines visual coherence. Custom overrides create maintenance debt and deviate from the IBM Design Language.
Recommendation
Map modal heading to Carbon's $heading-03 token (20px, weight 400). Audit all modal headings in the product for consistency.
Confidence
Medium — requires dev tools inspection
⚠ Needs dev tools inspection: Verify actual font-size and font-weight rendered values vs Carbon tokens.
Screen
Security Policies list — selected row
Standard
WCAG 1.4.3 (Contrast Minimum) — 4.5:1 for normal text, 3:1 for large text. The selected row ("-MilvuswBlocking") shows white text on a dark blue (#0353E9-range) background. The "false" column value on the far right appears in a lighter blue-white that may not meet 4.5:1 against the row fill.
Why it matters
Users with low vision may not be able to read all column values in the selected row state, particularly date strings and boolean values.
Recommendation
Use Carbon's $layer-selected token and $text-on-color / $text-primary tokens for selected rows. Run a contrast check tool on the actual rendered colours.
Confidence
Medium — needs colour picker on live UI
⚠ Needs live UI colour sampling: Use browser devtools or a contrast checker (e.g. IBM Equal Access Checker) on the selected row state.
Screen
Create PolicyEdit Policy
Standard
Carbon Button — Ghost button or disclosure button pattern is appropriate for show/hide toggles. Using a plain blue underlined link for a toggle action misrepresents the interactive behaviour (navigation vs. in-page toggle). WCAG 4.1.2.
Why it matters
If coded as an <a>, AT users expect navigation. If it expands content in-place, it should be a <button> with aria-expanded. This mismatch causes incorrect user mental model.
Recommendation
Replace with a Carbon Ghost button or an Accordion component. If kept as a disclosure pattern, implement as <button aria-expanded="false">Show advanced options</button> and toggle to "Hide advanced options" when expanded.
Confidence
Medium — requires code inspection
⚠ Needs code inspection: Check element type (<a> vs <button>) and presence of aria-expanded.
Summary
| ID |
Finding |
Theme |
Severity |
Confidence |
| F-01 | No close (×) button on modal | Dialog | High | High |
| F-02 | Modal content overflow / no scroll affordance | Dialog | High | Medium |
| F-03 | Nested modal — Roles dialog | Dialog | Medium | High |
| F-04 | Dialog title "policy" — capitalisation error | Dialog | Low | High |
| F-05 | Initial focus destination not annotated | Accessibility | High | Medium |
| F-06 | Toggle no accessible label per row | Accessibility | High | High |
| F-07 | Row checkboxes lack row-context labels | Accessibility | Medium | Medium |
| F-08 | Criteria column truncated — no reveal | Accessibility | Medium | High |
| F-09 | Icon-only toolbar — no accessible labels | Toolbar | High | Medium |
| F-10 | Install split button chevron unlabelled | Toolbar | Medium | Medium |
| F-11 | Notification badge no AT text | Toolbar | Low | Medium |
| F-12 | No required fields legend | Form | High | High |
| F-13 | Category field — non-Carbon combo pattern | Form | Medium | High |
| F-14 | Modal title non-Carbon heading style | Visual | High | Medium |
| F-15 | Selected row contrast needs verification | Visual | Low | Medium |
| F-16 | "Show advanced options" — link vs button | Visual | Low | Medium |
Live / Assistive Technology Testing Checklist
| Test |
Related Findings |
Method |
| Keyboard-only navigation through Create Policy modal | F-01, F-05 | Keyboard (Tab / Shift+Tab / Esc) |
| Focus trap validation inside modal | F-05 | Keyboard |
| Screen reader modal announcement (title, role, focus) | F-01, F-03, F-04, F-05 | NVDA + Chrome / VoiceOver + Safari |
| Toggle announcement in rules table | F-06 | NVDA / VoiceOver |
| Checkbox row label announcement | F-07 | NVDA / VoiceOver |
| Toolbar icon-only button tooltip on focus | F-09 | Keyboard + screen reader |
| Install split button chevron label | F-10 | DOM inspection + screen reader |
| Selected row colour contrast | F-15 | IBM Equal Access Checker / axe |
| Modal scroll / viewport overflow at 768px | F-02 | Browser viewport resize |
Scope note: This is a first-pass D&UX review based on static screenshots only. Findings reflect observations visible in the provided screens and known Carbon / IBM Experience Standards requirements. Confidence levels are indicated per finding. All items flagged "⚠ Needs human validation" require live browser testing, keyboard testing, screen reader testing, or product context clarification before severity is finalised. This review does not cover performance, data validation logic, or back-end behaviour.