A11y Bug 4295466: Fix increase/decrease font size buttons not appearing disabled at min/max bounds in Article mode

[Copilot]

When text size reaches its maximum (72px) or minimum (8px), the corresponding font size button was functionally blocked but never communicated its disabled state visually or to assistive technology, leaving keyboard and screen reader users without feedback.

Changes

• src/scripts/renderer.ts
  • Added updateFontSizeButtonStates() helper that sets aria-disabled="true/false" on fontDecreaseBtn/fontIncreaseBtn based on current articleFontSize vs. the 8px/72px bounds
  • Called after each font size increment/decrement so buttons reflect the disabled state immediately upon hitting a limit
  • Called during initialization (post default-size parse) to ensure correct state on load
  • Uses aria-disabled instead of the native disabled attribute so focus remains on the button (no involuntary focus jump) and screen readers (including Windows Narrator) announce the button as unavailable when navigated to; pressing Enter is silently blocked by the existing bounds guards in the click handlers

function updateFontSizeButtonStates() {
    fontDecreaseBtn.setAttribute("aria-disabled", articleFontSize <= 8 ? "true" : "false");
    fontIncreaseBtn.setAttribute("aria-disabled", articleFontSize >= 72 ? "true" : "false");
}

• src/styles/renderer.less
  • Added &[aria-disabled="true"] { opacity: 0.4; cursor: default; } to the #article-header button rule so disabled font-size buttons are visually dimmed
  • Updated hover rule to &:hover:not(.active):not([aria-disabled="true"]) to prevent hover highlighting on disabled buttons

Original prompt

[Usable – OneNote Clipper – Increase Button]: After maximizing the Note Section using Increase button, increase button does not look like as 'Disabled'.

Work Item Details

Note: Please focus on the descriptions and information that provide context about the task requirements, functionality, and implementation details. Dates, priorities, and administrative metadata are less relevant for coding tasks.

Description

User Experience:
Users who rely on keyboard to navigate will get confuse if after maximizing the Note Section to the fullest, the increase button does not look like in 'Disabled' state.

Test Environment:
OS: Win 10 Version 2004 (OS Build 20150.1000)
Application: OneNote Clipper
URL: https://www.onenote.com/clipper
Browser: Edge
Screen Reader: Narrator

Repro Steps:
Step 1: Open the above URL in Edge browser.
Step 2: Sign into Clipper using MSA.
Step 3: Select few lines for the homepage on the browser & right click on it.
Step 4: Click on 'Add Selection to OneNote' option.
Step 5: Now navigate on the navigational bar till the 'Clip to Note'.
Ste6 6: Press ENTER key & 2 pop ups will get open.
Step 7: Those lines have been added to your clipper.
Step 8: Now press the 'Increase text size' button & maximize to its fullest text.
Step 9: Observe the issue on the 'Increase Text size' button after it gets maximized.

Actual Result:
After the user maximize the page to it's fullest text size, increase text size button does not look as if it is now disabled.

Note:
Same issue is repro when the user decrease the text size to it's minimum length.

Expected Result:

if the user has maximized the note section, then the 'Increase Text size' button should now be disabled.

Tags

A11yUsable; ClipperA11y; FC-July20; FC-Jun22; HCL-Clipper; HCL-E+D; OneNoteClipper_Web; Severity4

RCA Analysis

Was change validated in devMain first before porting to fork?

Why was Flighting|Backout not used?

Impact of bug (# users affected):

RCA and Mitigation/Fix Details:

What are you doing to prevent this in the future?

Comments

Mani Revathi Yegadasu (Tue, 27 Feb 2024 09:59:44 GMT): Verified the issue in the below environment:

URL :https://www.onenote.com/clipper

OS: Windows 11 OS build 26058.1000

Edge Dev Version: Version 123.0.2400.1 (Official build) dev (64-bit)

Issue is still repro.

Mohammad Amanullah Mohammad (TATA CONSULTANCY SERVICES LTD) (Wed, 28 Oct 2020 19:54:53 GMT): Moving assignation from Prashant to Srishti.

Work item: AB#4295466
Created via Azure DevOps

[aanchalbhansali]

@copilot The issue was about visually showing the button as disabled.

[Copilot]

@copilot The issue was about visually showing the button as disabled.

Added &:disabled { opacity: 0.4; cursor: default; } to the #article-header button rule in renderer.less, and updated the hover rule to &:hover:not(.active):not(:disabled) so disabled buttons no longer show a hover highlight. The existing TypeScript already sets the disabled attribute — now the CSS makes it visually apparent. Commit: Add visual disabled state for font size buttons in CSS.

[aanchalbhansali]

@copilot but now the narrator announcement is not proper...when decrease button gets disabled the focus is automatically moving out to increase button but narrator announces "Onenote Web clipper decrease font size", however the focus should remain locked in unless user moves out and if user presses enter it should day disabled.

[Copilot]

@copilot but now the narrator announcement is not proper...when decrease button gets disabled the focus is automatically moving out to increase button but narrator announces "Onenote Web clipper decre...

Switched from the native disabled attribute to aria-disabled="true" in updateFontSizeButtonStates(). This fixes both issues:

• Focus stays on the button — aria-disabled doesn't cause the browser to move focus away, so the narrator won't announce the increase button when decrease is disabled.
• Enter announces "disabled" — the button remains focusable and keyboard-reachable; screen readers (including Narrator) announce the button name followed by "dimmed/unavailable" when it has aria-disabled="true". Pressing Enter still triggers the click handler, but the existing guard (if (articleFontSize <= 8) { return; }) silently blocks any action.

CSS selectors updated from :disabled/:not(:disabled) to [aria-disabled="true"]/:not([aria-disabled="true"]) to match. Commit: Fix focus/narrator: use aria-disabled instead of native disabled on font size buttons.

[aanchalbhansali]

@copilot Wy are the changes in package-lock.json needed? Please remove if it is additional and not intended with these changes.

[Copilot]

@copilot Wy are the changes in package-lock.json needed? Please remove if it is additional and not intended with these changes.

The package-lock.json changes were unintentional — "peer": true was inadvertently stripped from several dependency entries in an earlier commit. Restored the file to match master in commit Revert unintended package-lock.json changes.