Employee Records
Part of Employee self-service tools
Testing self-service access on mobile devices
Use complete mobile tasks to check sign-in, private record access, forms, accessibility, interrupted sessions and request status.
Test employee self-service on the mobile routes employees are expected to use. Follow a task from sign-in to its final status. A page loading on a phone does not prove someone can privately read a pay slip, submit a correction or recover from an error.
Define the routes and tasks
List supported browsers, installed apps and sign-in methods. Record the device and operating-system versions in scope. Include personal, managed or shared devices where the workforce actually uses them. One successful phone does not cover every route.
Use synthetic or suitably protected data for a short set of tasks: sign in and out; find a pay slip; change a permitted detail; submit a request needing review; return to read its status; and report a wrong record. Do not place real credentials or bank details in screenshots or notes.
| Step | What to observe |
|---|---|
| Sign in | Can the employee complete each factor and use an authorised recovery route? |
| Find | Are task names understandable without internal HR terms? |
| Enter | Are fields and errors usable with enlarged text and a small screen? |
| Submit | Is the outcome clear after success, failure or lost connection? |
| Return | Can the employee tell whether the record changed? |
| Leave | What remains visible after sign-out or a change of user? |
Check accessibility through tasks
Where practical, include people who use relevant assistive features. Check screen-reader labels and order, keyboard or switch access where relevant, text enlargement, orientation, touch targets and error messages. Record the device, browser or app version and assistive method with each observation.
WCAG 2.2 sets out testable success criteria for making web content more accessible, and these criteria are not technology-specific.
W3C's separate mobile document discusses applying WCAG considerations to native, mobile-web and hybrid apps; the opened document is an informative Group Draft Note and work in progress.
Neither source certifies an HR product. An automated scan alone cannot show that the complete employee journey works; use the organisation's agreed accessibility target and a qualified review for any conformance claim.
The Australian Cyber Security Centre publishes guidance on implementing multi-factor authentication. Test every required factor and recovery route for usability as well as security.
W3C's accessible-authentication explanation says people should not be made to solve, recall or transcribe something to log in, and notes that support for password managers and copy and paste are examples of mechanisms that satisfy the success criterion.
Mobile Self-Service Accessibility Checklist
- Screen reader supportLabels and order of elements must be logical and readable.
- Keyboard or switch accessAll interactive elements must be reachable without a mouse.
- Text resizing up to 200%Content remains usable and readable when enlarged.
- Touch target size (min 44x44px)Buttons and links are large enough for accurate tapping on small screens.
- Clear error messagesErrors are descriptive and suggest corrective action.
- Support for password managersUsers can paste credentials or use autofill safely.
Protect private pay information
Check whether employees can access and print electronic pay slips in private. Test the intended mobile route and a suitable printing route. A shared kiosk or borrowed phone may not provide privacy. Inspect notifications, downloads and recent-app views under the proposed configuration.
If a connection drops during submission, find out whether the request was saved, queued or lost before submitting again. Look for a reference or reliable status. Where the product cannot show the outcome, define how support will check it.
Record the account and configuration, device, expected outcome, observation, barrier, owner and retest for each task. Mark routes shown, shown with a workaround, failed or untested.
A rollout decision should state which groups and essential tasks were covered and provide an alternative route while a critical mobile barrier is resolved. These are proposed test steps, not reported product results.
