-
Notifications
You must be signed in to change notification settings - Fork 0
π¨ Palette: λΉλνν μμ ν΄ν ν€λ³΄λ μ κ·Όμ± κ°μ #445
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
a29cc19
feat: λΉλνν μμ ν΄ν ν€λ³΄λ μ κ·Όμ± κ°μ
seonghobae 8110dc6
feat: λΉλνν μμ ν΄ν ν€λ³΄λ μ κ·Όμ± κ°μ
seonghobae 558cc17
fix(security): upgrade Hono past 2026 CVEs
seonghobae f62e574
fix(security): regenerate dependency lock
seonghobae 9186df5
ci(security): align CodeQL with Hono remediation
seonghobae 24c8648
chore(security): keep Hono remediation dependency-only
seonghobae d30d218
Merge Hono security fix into tooltip accessibility improvement
seonghobae 6afa0d4
feat: λΉλνν μμ ν΄ν ν€λ³΄λ μ κ·Όμ± κ°μ
seonghobae cb3390d
feat: λΉλνν μμ ν΄ν ν€λ³΄λ μ κ·Όμ± κ°μ
seonghobae 1648076
feat: λΉλνν μμ ν΄ν ν€λ³΄λ μ κ·Όμ± κ°μ
seonghobae c3f6a81
feat: λΉλνν μμ ν΄ν ν€λ³΄λ μ κ·Όμ± κ°μ
seonghobae File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
π― Functional Correctness | π Major | β‘ Quick win
π§© Analysis chain
π Script executed:
Repository: ContextualWisdomLab/scopeweave
Length of output: 16304
π Script executed:
Repository: ContextualWisdomLab/scopeweave
Length of output: 50386
π Script executed:
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:
π 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:
π 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:
π 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:
ν¬μ»€μ€ κ°λ₯ν λΉλνν μμμ μ κ·Όμ± μλ―Έλ₯Ό λΆμ¬νμΈμ.
νμ¬
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