Decision inputs
Facts that change the policy answer
The request sits in product and design and connects screens, interaction descriptions and accessibility criteria with possible accessibility issues and fixes. That context distinguishes it from a generic permission to use AI.
- 1Task and owner
- Product designer wants to review a design for accessibility issues. Record the person who will stand behind possible accessibility issues and fixes after the tool has finished.
- 2Information involved
- Screens, interaction descriptions and accessibility criteria. The classification must cover what the tool can retrieve as well as what the requester types.
- 3Tool and account
- An approved company account. Treat a new plug-in or connector as a change to the approved setup.
- 4Intended result
- The expected result is possible accessibility issues and fixes. Its destination matters: private working material creates a different consequence from a sent, published or automated result.
- 5Consequence if it is wrong
- Automated review cannot observe every assistive-technology interaction or user need. This is the fact most likely to move the request from routine handling into review.
- 6Human review
- accessibility specialist or product owner should inspect, change, reject or stop the result. Review is meaningful only when that person has enough context and authority to change the result.
Possible policy routes
The task name alone cannot decide it.
A published workplace policy can return different answers for the same task. These are the practical branches worth encoding.
A routine policy route may be possible
A routine route is easier to justify when the exact account is approved, only the minimum product design information is used, possible accessibility issues and fixes remains within the stated purpose, and accessibility specialist or product owner reviews it before use.
Approval may be required
A named reviewer should take over when the account or data handling is uncertain, automated review cannot observe every assistive-technology interaction or user need, or possible accessibility issues and fixes reaches people or systems beyond the requester’s authority.
The request may need to stop or change
The policy may require another method where restricted information would enter an unapproved service, the output would act before accessibility specialist or product owner can intervene, or combine automated suggestions with keyboard, screen-reader and user testing cannot be maintained. Consider less information, a controlled account or a non-AI process.
Request checklist
Questions to ask before using the tool
- 01
Does the selected account retain or reuse anything supplied while trying to review a design for accessibility issues?
- 02
Who is permitted to expose screens, interaction descriptions and accessibility criteria to this tool and for this purpose?
- 03
Does possible accessibility issues and fixes create an external statement, a decision or an automated action?
- 04
Who replaces accessibility specialist or product owner when the request falls outside ordinary expertise?
- 05
Is this genuinely one request, or will repeated use turn it into an embedded process?
Worked request
What the employee should submit
This example supplies decision facts without pasting the underlying material into the approval record.
- requester
- product designer
- task
- Use AI to review a design for accessibility issues.
- information
- screens, interaction descriptions and accessibility criteria
- tool
- An approved company account
- frequency
- Recurring work
- region
- Where the work and affected people are located
- purpose
- Analyse
- impact
- Accessibility
- review
- Complete human review
- owner
- accessibility specialist or product owner
Useful safeguards
Controls that fit this request
- ✓
Combine automated suggestions with keyboard, screen-reader and user testing
- ✓
Separate source material from the request record and expose only what the tool needs for possible accessibility issues and fixes.
- ✓
Set an expiry or review point when recurring work turns into a permanent process.
- ✓
Record the request and reviewer without copying unnecessary parts of screens, interaction descriptions and accessibility criteria into the audit trail.
Questions people ask
About this AI use
Is using AI to review a design for accessibility issues automatically allowed?
Treat this as a request pattern. The authoritative answer comes from the current company policy and the employee’s completed submission.
What belongs in the employee’s request?
Describe possible accessibility issues and fixes, identify screens, interaction descriptions and accessibility criteria, name the exact tool and account, explain who will receive or rely on the output, and state how accessibility specialist or product owner will review it.
How should a later reviewer understand this decision?
Record the request and reviewer without copying unnecessary parts of screens, interaction descriptions and accessibility criteria into the audit trail. A classification and controlled reference may be enough when copying screens, interaction descriptions and accessibility criteria would create unnecessary risk.