[$250] Screen Reader: Workspace-Workflow: Disabled 'Next' button is not announced as such

[nbhardwaj-del]

Action Performed:

Prerequisite:
User is logged in
User has created at least one workspace

1. Using JAWS + Chrome, open the page https://new.expensify.com/workspaces
2. Navigate using TAB to any workspace created, press enter to activate
3. Navigate using TAB to 'Workflows' located in the middle navigation column, press enter to activate
4. Navigate using TAB to the 'Add Approval Workflow' button, press enter to activate
5. Navigate using TAB to the disabled 'Next' button at the bottom of the menu
6. Observe the announcement

Expected Result:

When users navigate to the disabled 'Next' button will announced as disabled to users
Expected announcement:
-"Next, disabled, button"

Actual Result:

When users navigate to the disabled 'Next' button in the 'Expenses from' menu, the screen reader does not announced its state as disabled, The screen reader only announces 'Next, button', thus indicating the button is active and available for interaction. Hence the screen reader will not be aware of the state of the button.

Next

Area issue was found in:

Workspace Workflow

Failed WCAG checkpoints

WCAG 4.1.2 Name, Role, Value
https://www.w3.org/WAI/WCAG22/Understanding/name-role-value

User impact:

Providing role, state, and value information on all user interface components enables compatibility with assistive technology, such as screen readers, screen magnifiers, and speech recognition software, used by people with disabilities.

Suggested resolution:

Use aria-disabled attribute and set its value to true to announce to users when the button is disabled

Refer:
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-disabled

Environment(s)

Windows Windows 10 - Chrome

Screenshots/Videos

Bug6996252_1762448957565.Disabled_next_button_not_announced_as_such.mp4

Version Number: NA
Reproducible in staging?: NA
Reproducible in production?: Yes
Email or phone of affected tester (no customers): NA
Logs: https://stackoverflow.com/c/expensify/questions/4856 NA
Notes/Photos/Videos: Any additional supporting documentation Yes
Expensify/Expensify Issue URL: https://platform.applause.com/company/12102/products/36605/community-issues/6996252
Issue reported by: NA
Slack conversation: NA

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022013150999572026570
• Upwork Job ID: 2013150999572026570
• Last Price Increase: 2026-01-26

Issue Owner

Current Issue Owner: @Krishna2323

[mavrickdeveloper]

PROPOSAL

Please re-state the problem that we are trying to solve in this issue.

When users navigate to the disabled 'Next' button in the 'Expenses from' menu, the screen reader does not announced its state as disabled, The screen reader only announces 'Next, button', thus indicating the button is active and available for interaction. Hence the screen reader will not be aware of the state of the button.

What is the root cause of that problem?

1-WorkspaceWorkflowsApprovalsExpensesFromPage.tsx Uses FormAlertWithSubmitButton with isDisabled prop

App/src/pages/workspace/workflows/approvals/WorkspaceWorkflowsApprovalsExpensesFromPage.tsx

Lines 140 to 154 in d34df44

	let buttonText = isInitialCreationFlow ? translate('common.next') : translate('common.save');
	if (shouldShowListEmptyContent) {
	buttonText = translate('common.buttonConfirm');
	}
	return (
	<FormAlertWithSubmitButton
	isDisabled={!shouldShowListEmptyContent && !selectedMembers.length}
	buttonText={buttonText}
	onSubmit={shouldShowListEmptyContent ? () => Navigation.goBack() : nextStep}
	containerStyles={[styles.flexReset, styles.flexGrow0, styles.flexShrink0, styles.flexBasisAuto]}
	enabledWhenOffline
	/>
	);

2-FormAlertWithSubmitButton.tsx / Passes isDisabled to Button

App/src/components/FormAlertWithSubmitButton.tsx

Lines 139 to 155 in d34df44

	) : (
	<Button
	ref={buttonRef}
	success
	shouldBlendOpacity={shouldBlendOpacity}
	pressOnEnter={pressOnEnter}
	enterKeyEventListenerPriority={enterKeyEventListenerPriority}
	text={buttonText}
	style={style}
	onPress={onSubmit}
	isDisabled={isDisabled}
	isLoading={isLoading}
	danger={isSubmitActionDangerous}
	medium={useSmallerSubmitButtonSize}
	large={!useSmallerSubmitButtonSize}
	onMouseDown={shouldPreventDefaultFocusOnPress ? (e) => e.preventDefault() : undefined}
	/>

3-BaseGenericPressable.tsx / The core issue location

App/src/components/Pressable/GenericPressable/implementation/BaseGenericPressable.tsx

Lines 175 to 187 in d34df44

	accessibilityState={{
	disabled: isDisabled,
	...rest.accessibilityState,
	}}
	aria-disabled={isDisabled}
	aria-keyshortcuts={keyboardShortcut && `${keyboardShortcut.modifiers.join('')}+${keyboardShortcut.shortcutKey}`}
	// ios-only form of inputs
	onMagicTap={!isDisabled ? voidOnPressHandler : undefined}
	onAccessibilityTap={!isDisabled ? voidOnPressHandler : undefined}
	accessible={accessible}
	fsClass={forwardedFSClass}
	// eslint-disable-next-line react/jsx-props-no-spreading
	{...rest}

aria-disabled={isDisabled} is set at line 179, but {...rest} is spread AFTER at line 187. This means:
If any parent component passes props that could affect aria-disabled or accessibilityState, those values from {...rest} would override our explicit accessibility settings
In JSX, when the same prop is set multiple times, the last one wins
The accessibility props should be set AFTER the rest spread to ensure they always take precedence

What changes do you think we should make in order to solve the problem?

BEFORE (problematic):

accessibilityState={{ disabled: isDisabled, ...rest.accessibilityState }}
aria-disabled={isDisabled}
accessible={accessible}
// ...
{...rest}  // <----- Could override accessibility props

AFTER (FIX):

{...rest}  // ← Spread first
// accessibility props - placed after {...rest} to ensure they take precedence
accessibilityState={{
    ...rest.accessibilityState,
    disabled: isDisabled,  // <-----  Our value wins (comes last)
}}
aria-disabled={isDisabled}  // <-----  Always correctly set
accessible={accessible}

With that ,The accessibility props now come after {...rest}, ensuring aria-disabled={isDisabled} always reflects the computed disabled state and screen readers will properly announce "disabled" for disabled buttons.

[melvin-bot]

Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[melvin-bot]

10 days overdue. Is anyone even seeing these? Hello?

[melvin-bot]

This issue has not been updated in over 14 days. eroding to Weekly issue.