The PRD positions Studio course authoring as the next major surface for the shared AuthZ service after Libraries v2. This phase focuses on Admin Console UX for roles, permissions and scopes; safer delegation; cross-scope management; and clearer visibility into who has access where, without changing LMS authorization behavior for existing actions in the short term.

• Create/own the Role × Capability × Scope (MVP) matrix (allow/deny for key actions, including local vs inherited).

• Define the MVP scope model (which scopes are first-class: course/org/global) and inheritance rules.

• Translate Product decisions into Admin Console IA, flows, UI states, and microcopy that are consistent and unambiguous.

• Define and document expected interaction patterns (including keyboard and focus behavior) and safety guardrails for high-risk actions.

• Identify terminology ambiguities and propose a glossary/naming convention for Console and Studio surfaces.

• Document design-impacting dependencies and open questions and ensure they are reflected in deliverables and handoff.

• Confirm enforceability constraints (publish permission feasibility, files/uploads behavior, settings served by single endpoints).

• Confirm data availability for cross-scope views, user audit, and audit logs (who/when/which scopes).

This maps PRD requirements to design outcomes and inputs needed to proceed. Scoped for the Design Phase SOW (not technical implementation ownership by Design).

• Confirmed MVP scope for first-class scopes (course/org/global) and cross-scope depth (views vs actions).

• Product-owned Role×Capability×Scope matrix available (or a working draft with explicit open decisions). @Guillermo Viedma

• Prioritized MVP coverage list for PRD 4.1 functional areas (in-scope vs phased).

• Entry point strategy decisions:

  • Studio in-context (R6.2)

  • General entry/landing (R6.3)

  • LMS Instructor Dashboard role assignment (redirect vs deprecate)

• Working hypotheses for:

  • publish permission

  • files/uploads permission modeling

  • learner data vs aggregate analytics boundaries

• Draft glossary/naming conventions for Console/Studio terms.

• Admin Console IA + navigation map covering (Documentation in Confluence): ○ In-context entry point from Studio to a specific course in Console

https://www.figma.com/design/onU2END2OXaF7RRLWEHsZI/AuthZ---v2?node-id=6032-10596&t=Nk8p0cMuTW548YYe-0

Open

Open

Open

Open

These accessibility checklists define how accessibility is designed, implemented, and validated across the product lifecycle.

The checklists are intentionally separated into Design and Development, while sharing a common conceptual framework based on the WCAG 2.1 POUR principles.

This checklist focuses on design-time decisions:

• How information is structured and perceived

• How users understand actions, risks, and consequences

• How interaction patterns prevent errors before they happen

• How inclusive the experience is for users with different abilities

It ensures that accessibility is embedded in the UX, not added later as a technical fix.

This checklist focuses on technical implementation and compliance:

• Correct semantic structure and ARIA usage

• Keyboard accessibility and focus management

• Screen reader compatibility

• WCAG 2.1 Level AA technical requirements

It ensures that accessible design decisions are correctly implemented in code and validated before release.

UX / UI / Product — Design phase

☐ Information is not conveyed by color alone
☐ Visual hierarchy reflects importance, risk, and impact
☐ States (active, selected, disabled, error, inherited, locked) are visually distinct
☐ Text is readable without relying on tooltips or hover
☐ Text remains readable at different sizes (zoom / responsive)
☐ Critical information is never embedded only in images
☐ Key information is visible without interaction

☐ All actions can be performed without precision, hover, or drag-only gestures
☐ Interactive elements are clearly identifiable as interactive
☐ Target sizes are sufficient for touch and pointer use
☐ Focus order follows the decision and reading flow
☐ No interaction depends on complex gestures
☐ Critical actions are visually separated from safe actions
☐ Modals and confirmations are intentionally placed in the flow

☐ Labels and terminology use human, non-technical language
☐ Similar actions or permissions are clearly distinguishable
☐ The impact of actions is clear before confirmation
☐ Warnings explain consequences, not just rules
☐ Error prevention is prioritized over error recovery
☐ The UI does not require prior domain knowledge
☐ RBAC-specific:

• ☐ Users can clearly understand what access they are granting

• ☐ High-risk permissions are visually and conceptually separated

• ☐ Self-lockout scenarios are clearly warned or prevented

☐ Components follow standard interaction patterns
☐ Custom behavior is intentional and documented
☐ Dynamic changes (state, visibility, permissions) are conceptually clear
☐ Designs support assistive technology interpretation
☐ Components can be implemented using semantic HTML
☐ Accessibility requirements are explicitly documented for dev handoff

Engineering / QA — Development phase (WCAG 2.1 AA)

☐ All informative images have correct text alternatives
☐ Decorative images are properly marked
☐ Icons conveying meaning have accessible names
☐ Color contrast meets WCAG 2.1 AA:

• Normal text: 4.5:1

• Large text: 3:1

☐ Information is not conveyed by color alone
☐ Text remains readable and functional at 200% zoom
☐ Content adapts correctly across screen sizes

☐ All functionality is keyboard operable
☐ Focus order matches visual and logical order
☐ Focus indicators are visible and meet contrast requirements
☐ No keyboard traps exist
☐ Touch targets meet minimum size (44x44 px)
☐ No interaction relies on hover-only or gesture-only input
☐ Modals:

• ☐ Focus moves into the modal on open

• ☐ Focus is trapped inside

• ☐ Focus returns to the trigger on close

☐ Page language is correctly defined
☐ Language changes are properly marked
☐ Components behave predictably
☐ No unexpected context changes occur
☐ Form fields have visible, associated labels
☐ Required fields are communicated programmatically
☐ Errors are clearly explained and announced
☐ Error states do not rely on color alone
☐ Suggestions are provided to fix errors

☐ Semantic HTML elements are used whenever possible
☐ Headings follow a logical hierarchy
☐ Landmark regions are defined where appropriate
☐ Interactive elements expose name, role, and state
☐ ARIA is:

• ☐ Used only when necessary

• ☐ Valid and correctly applied

☐ Dynamic state changes are announced to assistive technologies
☐ Screen readers interpret the UI correctly (NVDA / VoiceOver)

☐ Permission states (enabled, inherited, locked, restricted) are programmatically exposed
☐ Permission changes are announced to screen readers
☐ Tables expose proper headers and relationships
☐ Confirmation dialogs describe impact clearly
☐ High-risk changes require accessible confirmation

☐ Animations respect prefers-reduced-motion
☐ No content flashes more than three times per second
☐ Autoplay media can be paused or stopped

☐ Full keyboard-only navigation tested
☐ Screen reader testing completed
☐ Automated accessibility checks run (Axe, Lighthouse, WAVE)
☐ Accessibility issues documented with severity and ownership

☐ Meets WCAG 2.1 – Level AA
☐ No critical or high accessibility issues remain
☐ Exceptions are documented and approved

1. Content Editor: Can the role publish? If not, what is the default publishing expectation for typical teams?

2. Files/uploads: Is file management part of content editing or a separate permission area?

3. Entry points: Product decision for LMS Instructor Dashboard role assignment — redirect to Console or deprecate?

4. Console entry strategy: single global entry vs separate all-courses/all-libraries entries (or both)?

5. Bulk MVP: which primary bulk flow (multi-user in one scope vs one user across multiple scopes)?

6. Taxonomies/tags: parity only (current behaviors) or net-new taxonomy editing features?

7. Export restriction: should export be restrictable for IP protection in this iteration or future?

1. Instructor Dashboard reroute: technical plan to redirect role assignment to Console? required UI messaging?

From Product

• Any updated role definitions/evidence for roles (Auditor, Content Editor).

• One-page MVP coverage summary for PRD 4.1 (in-scope vs phased).

• Decision owners per topic (roles, Instructor Dashboard entry point, taxonomy parity).

From Tech

• Enforceability constraints (publish/files/settings) + recommended MVP simplifications.

• Data/API constraints for cross-scope views, user audit, filters/search, audit logs.

• Scope - Access: “The technical name is Scope, but for the final user, is Access.” The boundary where a role applies (this course / all courses in org X / all courses platform-wide).

• Local assignment: Role granted directly on a specific course/library scope.

• Inherited access: Access derived from a higher-level scope (org/global).

• Other users with access: Users who have access via higher scopes and are not in the local team list.

• Content Editor: Authoring-focused role that can edit content but is limited from learner data and certain settings (exact boundaries TBD).

• Auditor: View-only authoring role that can see unpublished content but cannot edit or change settings.

• Roles and permissions CTA: All entry points to the admin console have the “Roles and permissions CTA, while the console only have RBAC settings. Except Library, this entry point maintains Manage Access.