🎨 Palette: 비대화형 요소 툴팁 키보드 접근성 개선

[seonghobae]

💡 무엇을

• 프로젝트 전체 일수 및 진척률(계획/실적)을 보여주는 카드(.meta-value-card) 3개에 tabindex="0"을 추가했습니다.
• 표 내 진행상태 배지(.status-badge) 중 부가 설명(description)이 존재하는 경우에 한해 동적으로 tabindex="0" 속성을 추가하도록 자바스크립트를 수정했습니다.
• 이들 요소가 키보드 포커스를 받을 때 시각적으로 인지할 수 있도록 styles.css의 :focus-visible 선택자 규칙을 확장하여 브라우저 기본 외곽선 대신 일관성 있는 파란색 윤곽선이 나타나도록 처리했습니다.

🎯 왜

• div나 span 등 비대화형 요소에 title 또는 aria-label 속성으로 부가 정보나 툴팁을 제공하더라도, 마우스 호버 기능만 동작할 뿐 키보드를 사용하는 사용자나 화면 판독기 환경에서는 요소로 진입할 방법이 없어 정보를 얻을 수 없는 접근성 결함이 있었습니다.
• 키보드 내비게이션을 지원함으로써 모든 사용자가 숨겨진 상태 배지 설명과 진척률 카드의 상세 설명을 이용할 수 있도록 개선합니다.

📸 변경 전/후

변경 전:

• 키보드의 Tab 키를 통해 프로젝트 카드 영역이나 툴팁이 있는 상태 배지로 이동할 수 없었습니다.
• 사용자는 시각적 호버 기능 없이 제공되는 부가 텍스트(title 속성 등)를 확인할 수 없었습니다.

변경 후:

• Tab 키를 누르면 상단 요약 카드들과 WBS 표 내의 각 상태 배지에 포커스가 맺히며, 뚜렷한 파란색 테두리(focus-visible)가 나타납니다. 화면 판독기가 정보를 정상적으로 읽어낼 수 있습니다.

♿ 접근성

• 키보드 접근성: 비대화형 요소에 의도적인 tabindex="0" 부여.
• 시각적 포커스 명확성: 브라우저 기본 포커스 외곽선 대신 애플리케이션의 디자인 시스템에 맞는 눈에 띄는 상태(box-shadow) 제공.

---

PR created automatically by Jules for task 744094641182118282 started by @seonghobae

Summary by CodeRabbit

• 접근성 개선
  • 진행 상태 배지와 요약 카드가 키보드로 포커스될 수 있도록 개선했습니다.
  • 키보드 포커스 시 시각적 아웃라인을 제공해 현재 선택된 요소를 쉽게 확인할 수 있습니다.
  • 비대화형 정보 요소의 접근성 안내를 보강했습니다.

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[coderabbitai]

📝 Walkthrough

Walkthrough

설명 정보를 가진 요약 카드와 상태 배지를 키보드 포커스 대상으로 변경했습니다. :focus-visible 스타일을 추가하고, 비대화형 요소의 키보드 접근성 지침을 문서화했습니다.

Changes

키보드 포커스 접근성

Layer / File(s)	Summary
포커스 대상 및 시각적 피드백 .jules/palette.md, index.html, app.js, styles.css	비대화형 요소에 tabindex="0"을 사용하고 :focus-visible 피드백을 제공하는 지침을 추가했습니다. 요약 카드와 상태 배지를 키보드 포커스 대상으로 설정했습니다. 공통 포커스 아웃라인 스타일을 적용했습니다.

Estimated code review effort: 2 (Simple) | ~5 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	제목은 비대화형 요소의 툴팁에 대한 키보드 접근성 개선이라는 변경 사항의 핵심을 명확하게 설명합니다.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jules-744094641182118282-bc4eacb1

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

Superseded by #450. The current replacement carries the complete buyer-visible keyboard-focus scope from this PR (tabindex on the three tooltip summary cards, focusable described status badges, and matching :focus-visible treatment) and adds the missing semantic role boundary on both surfaces. Keeping both branches open would create competing implementations of the same four-file accessibility slice. No check, review, or approval from this PR transfers to #450.

[google-labs-jules]

Superseded by #450. The current replacement carries the complete buyer-visible keyboard-focus scope from this PR (tabindex on the three tooltip summary cards, focusable described status badges, and matching :focus-visible treatment) and adds the missing semantic role boundary on both surfaces. Keeping both branches open would create competing implementations of the same four-file accessibility slice. No check, review, or approval from this PR transfers to #450.

Understood. Acknowledging that this work is now obsolete as it has been superseded by #450, and stopping work on this task.

[seonghobae]

@coderabbitai review

Please review exact head d30d21824f5c57a3cfa89ec2655efe40b5b5604b against stacked security base 24c86489800ef4405e737a8e3d5bc3d54d7628dd. This non-force two-parent merge carries the Hono CVE remediation from #469 into an otherwise path-disjoint product change; predecessor-head review/check evidence is not reused.

[coderabbitai]

@seonghobae I will review d30d21824f5c57a3cfa89ec2655efe40b5b5604b against 24c86489800ef4405e737a8e3d5bc3d54d7628dd. I will not reuse predecessor review or check evidence.

⚠️ Action not completed

Review rate limited.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@index.html`:
- Around line 31-42: Update the focusable summary cards in index.html:31-42 to
use an appropriate non-generic role, assign IDs to their visible labels and
descriptions, and connect each card with aria-labelledby and aria-describedby
while preserving tabindex. In app.js:999-1002, update the status badge with an
appropriate non-live role and description reference; do not use role="status"
for static table cells.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 32023607-c2e0-4e1e-9843-4dcf7a75c730

📥 Commits

Reviewing files that changed from the base of the PR and between 74a5e99 and c3f6a81.

📒 Files selected for processing (4)

• .jules/palette.md
• app.js
• index.html
• styles.css

[coderabbitai]

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- candidate files ---'
git ls-files | rg '(^|/)(index\.html|app\.js|ARCHITECTURE\.md|AGENTS\.md|\.jules/)' || true

printf '%s\n' '--- index.html: relevant region ---'
nl -ba index.html | sed -n '1,75p'

printf '%s\n' '--- app.js: progress badge region ---'
nl -ba app.js | sed -n '950,1035p'

printf '%s\n' '--- related identifiers and render paths ---'
rg -n -C 3 'summary-total-days|summary-planned-progress|summary-actual-progress|progressState|description|renderAll\(' index.html app.js styles.css

printf '%s\n' '--- repository guidance ---'
for f in ARCHITECTURE.md AGENTS.md; do
  if [ -f "$f" ]; then
    printf '%s\n' "--- $f ---"
    sed -n '1,220p' "$f"
  fi
done
if [ -d .jules ]; then
  find .jules -maxdepth 2 -type f -print
fi

Repository: ContextualWisdomLab/scopeweave

Length of output: 16304

---

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- index.html: structure and labels ---'
awk 'NR >= 1 && NR <= 90 { printf "%4d %s\n", NR, $0 }' index.html

printf '%s\n' '--- app.js: status rendering and table context ---'
awk 'NR >= 680 && NR <= 755 { printf "%4d %s\n", NR, $0 }' app.js
awk 'NR >= 970 && NR <= 1010 { printf "%4d %s\n", NR, $0 }' app.js

printf '%s\n' '--- progress-state definitions and consumers ---'
awk 'NR >= 1415 && NR <= 1485 { printf "%4d %s\n", NR, $0 }' app.js
rg -n -C 4 'createStatusCellContent|status-badge|meta-value-card|summary-total-days|summary-planned-progress|summary-actual-progress' styles.css tests .jules 2>/dev/null || true

printf '%s\n' '--- relevant learning documents ---'
for f in .jules/*.md; do
  printf '%s\n' "--- $f ---"
  rg -n -C 2 'accessib|aria|focus|semantic|role|badge|summary|static|renderAll' "$f" || true
done

printf '%s\n' '--- accessibility-related tests ---'
rg -n -i -C 3 'accessib|aria|tabindex|role|keyboard|focus|status-badge|meta-value-card' tests 2>/dev/null || true

Repository: ContextualWisdomLab/scopeweave

Length of output: 50386

---

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- focused learning entry ---'
awk 'NR >= 100 && NR <= 125 { printf "%4d %s\n", NR, $0 }' .jules/palette.md

printf '%s\n' '--- targeted E2E accessibility assertions ---'
awk 'NR >= 1288 && NR <= 1335 { printf "%4d %s\n", NR, $0 }' tests/e2e/scopeweave.spec.js
awk 'NR >= 660 && NR <= 690 { printf "%4d %s\n", NR, $0 }' tests/e2e/scopeweave.spec.js

printf '%s\n' '--- focused source diff, if available ---'
git diff --unified=8 -- index.html app.js | sed -n '1,220p'

printf '%s\n' '--- deterministic attribute/label checks ---'
python3 - <<'PY'
from html.parser import HTMLParser
from pathlib import Path

class Parser(HTMLParser):
    def __init__(self):
        super().__init__()
        self.stack = []
        self.cards = []
        self.elements = []
    def handle_starttag(self, tag, attrs):
        attrs = dict(attrs)
        item = (tag, attrs, self.getpos()[0])
        self.elements.append(item)
        if 'tabindex' in attrs or 'tabIndex' in attrs:
            self.stack.append(item)
        if 'meta-value-card' in attrs.get('class', '').split():
            self.cards.append(item)

p = Parser()
p.feed(Path('index.html').read_text())
print('cards:')
for tag, attrs, line in p.cards:
    print({'line': line, 'tag': tag, 'tabindex': attrs.get('tabindex'),
           'role': attrs.get('role'), 'title': attrs.get('title'),
           'aria-label': attrs.get('aria-label'),
           'aria-labelledby': attrs.get('aria-labelledby'),
           'aria-describedby': attrs.get('aria-describedby')})
print('focusable static elements in index.html:')
for tag, attrs, line in p.elements:
    if 'tabindex' in attrs or 'tabIndex' in attrs:
        print({'line': line, 'tag': tag, 'tabindex': attrs.get('tabindex'),
               'role': attrs.get('role'), 'title': attrs.get('title'),
               'aria-label': attrs.get('aria-label'),
               'aria-labelledby': attrs.get('aria-labelledby'),
               'aria-describedby': attrs.get('aria-describedby')})
PY

Repository: ContextualWisdomLab/scopeweave

Length of output: 9206

---

🌐 Web query:

MDN tabindex non-interactive elements ARIA role focusable element title aria-describedby screen reader

💡 Result:

To ensure accessibility, developers should prioritize semantic HTML and follow established patterns for focus management. Tabindex and Interactive Elements The tabindex attribute allows authors to control the focusability of elements [1][2]. However, developers should avoid using tabindex to make non-interactive elements interactive [1][3]. Instead, use native interactive elements like button, a, or input, which have built-in keyboard support and ARIA semantics [1][2][3]. If a non-interactive element must be used for custom functionality, it should be made focusable by setting tabindex="0" [2][4][5]. Positive values for tabindex (e.g., tabindex="1") must be avoided, as they disrupt the logical navigation order [1][2][4]. A value of -1 makes an element focusable programmatically via scripting (e.g., using element.focus) but removes it from the sequential keyboard navigation flow [2][4][5]. ARIA Roles and Focus When using ARIA roles (such as role="button") on non-interactive elements, the element does not automatically gain keyboard interactivity or focus management [6][7]. Developers must manually implement the necessary event listeners for click and keydown events (including Enter and Space key support) and ensure the element is focusable via tabindex [6]. Browser support for ARIA roles is ignored on naturally focusable elements or elements with tabindex defined [8]. Aria-describedby and Screen Readers The aria-describedby attribute provides a way to associate additional text with an element, which is then communicated to screen reader users [9][10]. It is used to link an element to one or more descriptive elements by their IDs [9][10]. Unlike the title attribute, which may have limited or inconsistent support, aria-describedby is widely supported and intended for providing context or descriptions [9][11][10]. It is appropriate for plain text descriptions; for more complex or structured content, aria-details is recommended [9][10]. If both aria-describedby and aria-description are present, aria-describedby takes precedence [10].

Citations:

• 1: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/tabindex
• 2: https://developer.mozilla.org/en-US/docs/Web/Accessibility/Guides/Keyboard-navigable_JavaScript_widgets
• 3: https://web.dev/articles/control-focus-with-tabindex
• 4: https://webaim.org/techniques/keyboard/tabindex
• 5: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Accessibility/WAI-ARIA_basics
• 6: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/button_role
• 7: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles
• 8: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/presentation_role
• 9: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-describedby
• 10: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-description
• 11: https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/

---

🌐 Web query:

WAI-ARIA generic role aria-label prohibited accessible name focusable generic span role status static status badge

💡 Result:

The WAI-ARIA specification explicitly prohibits the use of aria-label and aria-labelledby on elements with the generic role [1][2][3]. The generic role is intended to be used by user agents for containers that have no specific semantic meaning and should not be used by web authors [1][4]. Applying an accessible name (via aria-label or aria-labelledby) to a generic element is a violation of the ARIA specification [5][6]. The prohibition exists because the generic role does not have a semantic concept of a name [5]. When an author applies these attributes to a generic element, behavior across screen readers is inconsistent [5][7][6]. Some screen readers (such as VoiceOver) may announce the label [5][7][6], while others (such as NVDA or JAWS) ignore it completely [5][7], leading to unpredictable and non-standard accessibility experiences [8][6]. Regarding focusability: A standard span or div with a generic role is not focusable by default. If such an element is made focusable (e.g., via tabindex="0"), it should typically be given a specific, meaningful ARIA role (such as button or checkbox) rather than remaining generic, as users expect focusable elements to have a clear role and purpose [8]. There are narrow exceptions where an element's role may change, allowing for a label: 1. When a section element is given an aria-label, its role is implicitly elevated from generic to region, which is a named landmark [5][7]. 2. When a div has the popover attribute, its role is elevated to group, which is a role that supports naming [5][7]. Unless the element's role is programmatically changed to one that supports naming, authors should avoid attempting to label generic containers [5][8]. If an accessible name is required, the best practice is to use an element that inherently supports that role (e.g., using a button for an interactive action) [5][8].

Citations:

• 1: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/generic_role
• 2: https://www.w3.org/TR/wai-aria-1.3/
• 3: https://w3c.github.io/aria/
• 4: https://www.w3.org/TR/html-aria/
• 5: https://sitebrace.com/learn/aria-label-on-divs
• 6: https://benmyers.dev/blog/dont-use-aria-label-on-static-text-elements/
• 7: https://www.matuzo.at/blog/2026/aria-label-generic-elements
• 8: https://rocketvalidator.com/accessibility-validation/accesslint/0.17/aria/aria-prohibited-attr

---

🌐 Web query:

W3C ARIA role status definition live region status badge role status accessibility

💡 Result:

The ARIA role status is a defined landmark role used to create an assertive or polite live region—specifically for advisory information—that does not require immediate user interruption [1][2]. Definition and Purpose The status role is intended for content that provides advisory information regarding the state of an application or user activity [1][3]. It is not appropriate for critical errors or alerts that require immediate, interrupting attention; for those, the alert role is preferred [1][2]. Common use cases include success confirmations, loading messages, or updates to a shopping cart [3][2]. Key Technical Characteristics When an element is assigned role="status", it carries the following implicit ARIA properties: - aria-live="polite": This ensures that assistive technologies (AT), such as screen readers, announce the update only when the user is idle, rather than interrupting their current task [1][3][4]. - aria-atomic="true": This informs the AT that it should present the entire contents of the status container when an update occurs, rather than just the changed portion [1][3]. Best Practices for Accessibility - Implementation: To ensure reliability across various browsers and assistive technologies, it is often recommended to add an explicit aria-atomic="true" attribute, even though it is implicit, to ensure consistent behavior [3][5]. Similarly, some developers add redundant aria-live="polite" attributes to maximize compatibility [4]. - Container Presence: For the best results, the element designated as the status region should be present in the Document Object Model (DOM) when the page loads, and then updated dynamically with content [3][4][6]. - Content Context: Because status is often atomic, developers should ensure the container includes enough context so that the announcement is meaningful on its own [3]. If the status message relies on visual icons, ensure equivalent text (such as alt text or aria-label) is included within the status container [3]. - Avoid Focus: The status role is designed to inform users of changes without requiring them to move their focus; do not manually move focus to a status region [1].

Citations:

• 1: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/status_role
• 2: https://a11ypath.com/guides/live-regions/
• 3: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22
• 4: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Guides/Live_regions
• 5: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22.html
• 6: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA19.html

---

🌐 Web query:

WAI ARIA Authoring Practices informational card group aria-labelledby aria-describedby noninteractive focusable

💡 Result:

There is no single, globally defined WAI-ARIA "card group" pattern [1]. Instead, accessibility for card groups is achieved by applying WAI-ARIA and HTML principles according to the specific interaction design (e.g., whether the group is static or interactive) [2][1]. Accessible Naming and Description To ensure assistive technologies identify and distinguish cards within a group: - Accessible Name: Use aria-labelledby to link the card to its primary heading (e.g., the card title) [3][4]. If no visible title exists, aria-label may be used as a fallback to provide a brief, descriptive name [2][3][4]. - Accessible Description: Use aria-describedby to associate the card with additional supporting information, such as body text or secondary details [2][5]. This provides context beyond the primary name [2]. Focusable vs. Non-interactive The interactivity of a card group determines its keyboard requirements: - Non-interactive Card Groups: If cards are primarily for information display, they generally do not need to be focusable [6]. Keyboard users navigate through the content naturally using standard page navigation (e.g., Tab key to reach links/buttons within cards) [6]. - Interactive/Selectable Card Groups: When cards act as components (e.g., selectable options or triggerable actions), they may be made focusable [7][5]. If a group contains multiple interactive elements, the WAI-ARIA Grid pattern or a roving tabindex approach is often used to manage focus, allowing users to navigate between cards using arrow keys while maintaining only one card in the page tab sequence [8][9][10]. Best Practices - Semantic HTML: Whenever possible, use native HTML elements (e.g., list items in an unordered list) to establish the group structure [5]. - Focus Management: If you choose to make cards focusable, ensure the focus indicator is clearly visible and that keyboard behavior (e.g., arrow key navigation) is consistent with familiar UI patterns [10][6]. - Avoid Redundancy: Do not use aria-labelledby or aria-describedby if the same information is already correctly identified by semantic structures (e.g., headings) that screen readers already announce [4]. Top results: [2][3][8][10][7]

Citations:

• 1: https://www.w3.org/WAI/ARIA/apg/
• 2: https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/
• 3: https://www.patternfly.org/components/card/accessibility/
• 4: https://pluma.customer.io/components/option-card/accessibility
• 5: https://www.telerik.com/kendo-react-ui/components/layout/card/accessibility/wai-aria-support
• 6: https://dap.berkeley.edu/accessible-card-ui-component-patterns
• 7: https://developers.arcgis.com/calcite-design-system/components/card-group/
• 8: https://www.w3.org/WAI/ARIA/apg/patterns/grid/
• 9: https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/layout-grids/
• 10: https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/

---

포커스 가능한 비대화형 요소에 접근성 의미를 부여하세요.

현재 div와 span은 tabindex="0"이 있어도 generic 요소로 남아 있습니다. span의 aria-label은 일관되게 노출되지 않을 수 있습니다.

• index.html:31-42: 포커스를 유지하면 이름을 지원하는 적절한 역할을 추가하고, 표시 레이블과 동적 값을 aria-labelledby로 연결하세요. 설명은 aria-describedby로 연결하세요.
• app.js:999-1002: 상태 배지에도 동작에 맞는 비-live 역할과 설명 연결을 추가하세요. 정적 표 셀에는 동적 알림을 만드는 role="status"를 사용하지 마세요.

📍 Affects 2 files

• index.html#L31-L42 (this comment)
• app.js#L999-L1002

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@index.html` around lines 31 - 42, Update the focusable summary cards in
index.html:31-42 to use an appropriate non-generic role, assign IDs to their
visible labels and descriptions, and connect each card with aria-labelledby and
aria-describedby while preserving tabindex. In app.js:999-1002, update the
status badge with an appropriate non-live role and description reference; do not
use role="status" for static table cells.

[seonghobae]

Closing this duplicate accessibility pattern.

Adding every informational summary card and every described status badge to the sequential tab order creates potentially thousands of non-actionable keyboard stops in a large WBS. It also continues to rely on title behavior rather than exposing the explanation as programmatically associated content. No browser/screen-reader test proves the proposed focus order or announcement.

#481 and #485 proposed the same strategy with different ARIA roles. A future replacement must preserve a concise task-oriented tab order and provide the exact explanatory values through visible text or an explicit accessible-description relationship.

[google-labs-jules]

Closing this duplicate accessibility pattern.

Adding every informational summary card and every described status badge to the sequential tab order creates potentially thousands of non-actionable keyboard stops in a large WBS. It also continues to rely on title behavior rather than exposing the explanation as programmatically associated content. No browser/screen-reader test proves the proposed focus order or announcement.

#481 and #485 proposed the same strategy with different ARIA roles. A future replacement must preserve a concise task-oriented tab order and provide the exact explanatory values through visible text or an explicit accessible-description relationship.

Understood. Acknowledging that this work is now obsolete, and stopping work on this task.