OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Portal Accessibility: Review the Whole Task Path

ServiceNow portal accessibility should be reviewed across the complete task: finding the service, understanding the content, completing the form, handling an error, checking status, and receiving a result. A visually tidy page can still block users when meaning, keyboard access, permissions, or feedback are unclear.

For ServiceNow portal owners reviewing whether users can understand and complete service tasks across access needs..

ServiceNow portal accessibilityaccessible service portalaccessible forms
Discuss this ServiceNow topic

Guide map

Checking every step of a portal task

Start with the user task and access need

Test the portal by asking a user with a specific access need to finish one real request from the first page to the confirmation.

Check navigation, content, and form meaning

Test the path from login to confirmation with a keyboard alone and with a screen reader, since a single gap can stop the whole task.

Review errors, status, and feedback

Trigger each error message in a test run and check that it names the field, explains the problem in plain words and says how to fix it.

The practical framework

Review ServiceNow portal accessibility across content, navigation, forms, status, errors, keyboard use, permissions, assistive needs, and task completion.

Start with the user task and access need

Identify the user, service, task, device or input context, information needed, and successful result. Review where the user starts and what decision or action must be possible without relying on one interaction method.

The ServiceNow service-portal route is the relevant internal destination when the portal is the service entry point.

Check navigation, content, and form meaning

Review headings, labels, instructions, required fields, choices, links, focus order, and language. The user should be able to tell what a service provides, what information is needed, and what happens after submission.

The ServiceNow user-adoption route provides an internal path when content and user guidance need improvement.

Review errors, status, and feedback

Confirm that errors identify the problem, location, correction, and next step. Status should explain whether the request was received, blocked, assigned, or complete. Feedback should not depend on colour or disappear before the user can understand it.

The ServiceNow request-status route is relevant when task feedback and status need design.

Test permissions and assistive paths

Test roles, access boundaries, keyboard or alternate input, focus, text alternatives, validation, and support paths. Record whether a restriction is intentional and how the user can obtain help without losing the task context.

The ServiceNow access-controls route supports review of permission boundaries.

Record barriers and ownership

Capture the task, barrier, consequence, evidence, owner, correction, workaround, and review date. Prioritise barriers that prevent a service outcome, not only cosmetic differences.

For portal accessibility review work, the ServiceNow continuous-improvement route provides the next internal path.

Common questions

Questions teams ask about portal accessibility

Is visual design enough to prove accessibility?

No. The user must be able to understand and complete the task across content, input, focus, permissions, error handling, status, and feedback conditions.

What should an accessibility review produce?

It should identify the task, barrier, affected user, evidence, consequence, owner, correction, workaround, and review condition.

The research-grounded boundary

A portal accessibility review needs defined inputs for each task, an accountable owner, a visible route for users who cannot complete a step, and evidence another person can check. For this review, that means naming the owner, the evidence, and the point at which a person checks or corrects the result. The review does not promise a universal outcome; it shows whether each step of the task can be completed and verified.

Walking one service request from start to result as a keyboard user

The fastest way to find accessibility barriers in a service portal is to attempt a real request using only a keyboard, then repeat it with a screen reader that the team actually has available. A page can look complete on a large monitor and still trap focus inside a date picker, hide the only error message below a fold the keyboard never reaches, or announce a confirmation before the form has finished submitting. None of those problems shows in a visual review, and an automated scan catches only a fraction of them.

Use a single realistic request, such as asking for access to a shared folder or reporting a damaged laptop, and walk it through each stage. The table lists the stages where barriers most often hide and the check that exposes each one.

Stage of the taskCommon barrierCheck to run
Finding the serviceSearch results that depend on internal names the user does not knowSearch using the words a user would type, and confirm the result is reachable by keyboard
Reading the instructionsEligibility stated only in an image or in colorRead the page with the images disabled and the text zoomed
Completing the formFields without visible labels, or with placeholders used as labelsTab through every field and confirm each one announces its purpose
Choosing dates, files or lookupsCustom widgets that a keyboard cannot operateComplete each widget using only the keyboard
Recovering from an errorErrors shown in one place only, or cleared before the user reads themSubmit with a deliberate error and confirm the message is announced and linked to the field
Checking progressStatus conveyed only by an icon or color changeRead the status with the screen reader and confirm the wording is complete

A test order that finds barriers early in the build

Accessibility problems are cheapest to fix before a form is copied across many services. The following order is useful when the portal is still being designed, and it works equally well for a review of a live service.

  1. Choose one service that represents the common task pattern, and write its steps as a short list of what the user must see, decide and submit.
  2. Complete the task using the keyboard alone, noting every point where focus disappears, becomes hard to see, or moves to an unexpected place.
  3. Repeat the task with a screen reader, listening for field labels, required indicators, group headings and the confirmation message.
  4. Deliberately submit the form with missing and invalid entries, and check that each error is identified, located and explained in a sentence the user can act on.
  5. Test the task with zoomed text and with a narrow window, because a layout that breaks at those sizes blocks users who rely on them.
  6. Record each barrier with the step it blocked, the user it affects, the change needed and the owner who will make it.

The final record matters because accessibility findings are easily lost when they are reported as a list of technical observations. A barrier that stops someone submitting a request is a service failure, and should be scheduled like one.

Which barriers to fix first, and which can wait

Not every barrier carries the same consequence. A missing alternative text on a decorative image is worth correcting but rarely blocks anyone. A keyboard trap in the only form that requests access to a system is a service failure. Prioritize barriers by whether they stop a person completing the task, then by how many services they affect, then by the effort to fix them. A shared component that repeats a barrier across many services should move higher than its individual size suggests, because one correction removes the barrier everywhere.

Does a passing automated scan mean the portal is accessible?

No. Automated checks can find missing labels and some contrast failures, but they cannot tell whether a sequence of steps makes sense to someone using a screen reader. The Web Content Accessibility Guidelines describe criteria that need human judgment as well as tools.

Who should own accessibility fixes in a portal that is built by several teams?

The portal owner should own the shared components and the standards they follow, while each service owner remains responsible for the wording, the fields and the eligibility rules in their own service. Without that split, shared barriers are repeatedly reported and never fixed.

Should a barrier be accepted when a phone route exists?

A phone route is a workaround, not a solution, and it should be recorded as one. It may be acceptable for a rarely used service while the fix is scheduled, but it should not become the standing route for a service people use every week.

How often should the review be repeated?

Repeat the review after each change to a shared component, a new form, or a change in the authentication or permission model, because those are the points where new barriers usually appear.

Reviewing one service portal path first

If your portal has several services that share the same forms and widgets, a review of one representative task often reveals barriers that affect several of them. The service portal widget explainer explains what a service portal widget is, and the self-service portal testing checklist covers testing and acceptance for a customer self-service portal.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading