Keep mobile approvals usable on a small screen

An approval button that fits on a phone does not guarantee that the approval task fits. Managers may need to compare amounts, inspect an attachment, and understand a changed request before deciding. Start with the evidence required for that decision. Then decide which approvals belong on mobile and which should offer a clear route to a larger workspace.

Put decision evidence ahead of controls

Agree a concise summary with the business owner. Include record identity, requester, purpose, and the values that affect approval authority. Show meaningful changes since the previous review, rather than making the manager reconstruct them from a long activity history.

Keep supporting detail available without placing every field above the action. For an attachment that cannot be read confidently on a phone, provide a way to defer the decision. Do not turn the absence of visible evidence into an instruction to approve anyway.

Let the layout adapt without hiding meaning

WAI describes reflow as presenting content without lost information or functionality at specified narrow dimensions, with exceptions for content requiring two-dimensional layout.[5] Use that guidance to review the approval summary at enlarged text and narrow widths. A desktop screenshot reduced to phone size is not a useful acceptance test.

Recommend clearly separated actions with explicit labels. Avoid placing a destructive rejection beside approval without enough distinction. For consequential submissions, WAI describes safeguards such as reversibility, checking, or confirmation within its stated scope.[7] Choose a safeguard that matches the actual business transaction.

Hypothetical example: approving equipment replacement

A hypothetical facilities lead reviews a replacement request on a phone. The summary names the equipment, explains why repair is unsuitable, and shows the proposed scope. An attachment contains the detailed inspection. The lead can open it or leave the request pending with a note.

Before approval, the interface repeats the record identity and the decision consequence. If another reviewer changes the request, the product asks the lead to review the current version. This scenario illustrates intended behavior, not a claim that a particular workflow or technical control already exists.

Accept the mobile journey under interruptions

Test a complete decision while the on-screen keyboard is open, the connection is slow, and the user returns from an attachment. Decide how the application reports an uncertain submission result. An approval should not appear complete merely because the button stopped responding. Ask the approver to enter a clarification note, then verify that the on-screen keyboard does not hide the relevant evidence or final action.

A compact summary can omit important context, while exhaustive detail can make the task unusable. Resolve that tradeoff with actual approvers. This checklist is a product review aid, not a formal accessibility assessment.

• Show the record and the decision-critical values before commitment.
• Keep attachments and changed information reachable.
• Offer defer or request-information paths when evidence is insufficient.
• Check enlarged text, narrow layouts, and the on-screen keyboard.
• Verify the saved decision before presenting a final confirmation.