disablePageTabIndex() sets aria-hidden on the focused calendar button, and enablePageTabIndex() never removes it
Maintainer thường phản hồi trong vòng 3 ngày
Chưa có ai nhận issue này.
- #709 của @arpitjain099 — đã đóng, không merge
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 68/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- playwright, typescript
- Lĩnh vực
- accessibility, frontend, testing
Hướng nghiên cứu
Bắt đầu với các phương thức khóa trang của DatepickerComponent trong picker.component.ts, sau đó chạy phạm vi kiểm thử Playwright cho datepicker trong test-app/e2e/datepicker.spec.ts và xem lại AGENTS.md để xác định ranh giới giữa Vitest và Playwright. Thay đổi được hoàn tất khi cây con lịch không bị ẩn, các trạng thái aria-hidden trước đó được giữ nguyên, các thuộc tính được khôi phục không còn tồn tại khi thích hợp và phạm vi kiểm tra console trong trình duyệt thực không báo cáo vi phạm nào.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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_focusableStringand handle the trigger separately. - Record prior
aria-hiddenalongsidedata-sam-tabindex(mirroringdata-sam-noinitial-tabindex) and remove vs. restore accordingly. - Chrome's own suggestion — the
inertattribute 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 focuswarning in the browser console on open - Closing the calendar removes
aria-hiddenfrom 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 expectaria-hidden="false") - Playwright coverage asserts the console produces no
aria-hiddenviolation — 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.
- Ngôn ngữ chính
- TypeScript
- Star
- 8
- Fork
- 33
- Merge trung bình
- 3 ngày 21 giờ
- Pull request đã merge (30 ngày)
- 9
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của GSA/sam-ui-elements
-
github_actions security
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 88/100
GSA/sam-ui-elements#761 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
tech-debt
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 56/100
GSA/sam-ui-elements#708 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
bugfix
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
GSA/sam-ui-elements#681 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Burn down ESLint and Angular lint debtCó thể làm lại được @fpigeonjr đã nhận 62 ngày trước và không có pull request nào đang mở. Đang mởangular-upgrade maintenance
GSA/sam-ui-elements#580 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 3 ngày
-
sam-ui-elements pipeline modernization + Angular 19→21 upgrade (SAM Angular upgrade — 4th tracer bullet) — IAEMOD-61187Có thể làm lại được @fpigeonjr đã nhận 74 ngày trước và không có pull request nào đang mở. Đang mởangular-upgrade maintenance
GSA/sam-ui-elements#562 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 3 ngày
Tất cả issue của GSA/sam-ui-elements
Issue tương tự
-
Plugin: sheet music can't be scrolled by hand before playbackCó thể đã có người làm @snakajima đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
receptron/jinglescript#51 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 9 ngày
-
clawsweeper:needs-maintainer-review clawsweeper:needs-product-decision clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster P3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
openclaw/openclaw#186424 · 1 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
chore(worker): five module header comments describe the code from before later issues changed itĐang mởarea:dev U2-later
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
bentleypark/aiwatch#1824 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Pal-AI-Lab/Coopanion#469 ·
Maintainer thường phản hồi trong vòng 1 ngày