disablePageTabIndex() sets aria-hidden on the focused calendar button, and enablePageTabIndex() never removes it

[fpigeonjr]

DatepickerComponent.disablePageTabIndex() stamps tabindex="-1" and aria-hidden="true" onto every focusable element on the page when the calendar opens — including the datepicker's own calendar button, which the user has just clicked and which the browser has focused. Chrome rejects the attribute and logs:

Blocked aria-hidden on an element because its descendant retained focus. The focus must
not be hidden from assistive technology users. [...] Consider using the inert attribute
instead, which will also prevent focus.
Element with focus:      <span.fa fa-calendar>
Ancestor with aria-hidden: <span role="button" tabindex="-1" class="fa fa-calendar"
                            aria-expanded="true" data-sam-tabindex="0" aria-hidden="true">

Reproduced in Chromium on the /datepicker gallery route (added in #666), immediately after a real click on the calendar icon:

{
  "activeElement": "<span role=\"button\" tabindex=\"-1\" class=\"fa fa-calendar\" aria-expanded=\"true\" data-sam-tabindex=\"0\" aria-hidden=\"true\">",
  "iconAria": "true",
  "iconTabindex": "-1"
}

Cause

The selector matches the component's own subtree:

_focusableString: string =
  'a[href], area, button, select, textarea, *[tabindex], input:not([type="hidden"])';

picker.template.html gives the calendar button tabindex="0", so *[tabindex] selects it. disablePageTabIndex() then walks document.querySelectorAll(this._focusableString) with no exclusion for this component, hiding the trigger the user is standing on. The masked input inside sam-input-mask is hidden for the same reason.

Second defect in the same pair of methods

enablePageTabIndex() does not restore the prior aria-hidden state — it unconditionally sets aria-hidden="false":

el.removeAttribute("data-sam-tabindex");
el.setAttribute("aria-hidden", "false");   // should be removeAttribute

tabindex is correctly restored (data-sam-noinitial-tabindex tracks elements that had none and removes the attribute), but aria-hidden has no equivalent bookkeeping. So every focusable element on the page is left permanently carrying aria-hidden="false" after the first open/close cycle — DOM pollution that also destroys any aria-hidden an element legitimately had before the calendar opened.

Note test-app/e2e/datepicker.spec.ts currently asserts aria-hidden="false" as the restored state, with a comment explaining the tabindex asymmetry. Fixing this requires updating those assertions to expect the attribute to be absent.

Suggested direction

• Exclude the component's own subtree when disabling — e.g. skip any element where this.wrapper/host .contains(el), or narrow _focusableString and handle the trigger separately.
• Record prior aria-hidden alongside data-sam-tabindex (mirroring data-sam-noinitial-tabindex) and remove vs. restore accordingly.
• Chrome's own suggestion — the inert attribute on a wrapper — would replace both loops with one attribute and is worth evaluating, though it changes the DOM contract these two methods expose.

Scope note

These methods are public on DatepickerComponent and are the general page-locking mechanism for this component, so the fix is not datepicker-cosmetic — it affects the a11y of any page that opens the calendar. Independent of #681 (missing CSS): this reproduces regardless of stylesheets.

Acceptance criteria

• Opening the calendar does not set aria-hidden="true" on the calendar button or any other element inside the datepicker
• No Blocked aria-hidden on an element because its descendant retained focus warning in the browser console on open
• Closing the calendar removes aria-hidden from elements that did not have it beforehand, rather than setting "false"
• An element that legitimately had aria-hidden="true" before the calendar opened still has it afterwards
• test-app/e2e/datepicker.spec.ts's restore assertions are updated accordingly (they currently expect aria-hidden="false")
• Playwright coverage asserts the console produces no aria-hidden violation — this is a real-focus/real-browser behaviour jsdom cannot reproduce, per AGENTS.md's Vitest/Playwright boundary

Context

Surfaced while manually testing #666 on the new /datepicker route. Pre-existing and unrelated to that PR's two-line fix (git diff on picker.component.ts touches only the @ViewChild decorator and the contains() comparison); kept separate to kept #666 scoped.