-
Notifications
You must be signed in to change notification settings - Fork 0
fix: harden Therapy Compass recovery and error accessibility #800
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
5 commits
Select commit
Hold shift + click to select a range
6370ec1
fix: harden Therapy Compass recovery and error accessibility
cursoragent 9206f11
fix: address Therapy Compass recovery review findings
cursoragent 33bbfd0
Merge remote-tracking branch 'origin/main' into cursor/therapy-compas…
cursoragent ec42c40
Merge remote-tracking branch 'origin/main' into cursor/therapy-compas…
cursoragent 89c9f09
Merge remote-tracking branch 'origin/main' into cursor/therapy-compas…
cursoragent 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
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
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 | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: BigSimmo/Database
Length of output: 4976
🌐 Web query:
CSS :focus-visible script focus after pointer interaction heuristics MDN💡 Result:
The:focus-visible pseudo-class applies to an element when it is focused and the browser's User Agent (UA) determines, through internal heuristics, that a visible focus indicator is necessary [1]. This allows developers to display focus styles only when they would be most helpful—primarily for keyboard users—while avoiding potentially distracting focus rings during pointer interactions [1][2][3]. Heuristics for:focus-visible The specific heuristics used by browsers are not defined normatively in the CSS specification, which grants UAs flexibility in implementation [4][5][6]. However, modern browser engines have converged on a common set of behaviors [2]: 1. Keyboard Interaction: If an element receives focus via a keyboard interaction (e.g., Tab key),:focus-visible will almost always match, as the user is clearly navigating by keyboard [1][2][3]. 2. Pointer Interaction: Generally, when an element is focused via a mouse click, touch, or other pointing device,:focus-visible does not match [1][3]. This prevents focus styles from "sticking" on elements like buttons after they are clicked, which can be confusing for users [7]. 3. Input Elements: Elements that require user input, such as text fields (e.g., or <textarea>), typically match:focus-visible regardless of how focus was received [1][2]. This is because it is essential for the user to know where their typed input will be placed [1][2]. Regarding the:focus-visible polyfill (WICG/focus-visible): Before widespread native support, a polyfill script was commonly used to achieve this behavior [8]. This script used its own set of heuristics to mimic native support [8][5]: - Keyboard Modality: It tracked whether the last interaction was a keyboard event (like Tab) and added a.focus-visible class accordingly [4][8]. - Focus Events: It would trigger focus visibility if an element that required keyboard interaction (like a text field) received focus [8]. - Limitations: Because the polyfill had to rely on events available to JavaScript, it could not perfectly replicate the internal, low-level browser heuristics, leading to slight variations in behavior compared to modern native implementations [8][5]. Today, developers are encouraged to use the native:focus-visible pseudo-class directly, as it is supported by all major browsers and integrates natively with the browser's own focus-tracking logic [1][2][8]. Top Results: [1][2][5][3]
Citations:
🌐 Web query:
MDN :focus-visible keyboard modality pointer programmatic focus💡 Result:
The:focus-visible pseudo-class is a CSS selector that matches an element only when the User Agent determines, via internal heuristics, that a focus indicator is necessary [1]. Its primary purpose is to distinguish between situations where a focus indicator is helpful (e.g., keyboard navigation) and where it might be considered obtrusive (e.g., clicking a button with a mouse) [1][2]. Regarding programmatic focus and modality: 1. Modality and Heuristics: Browsers use heuristics to determine the input modality [2]. Generally, if the user interacts via the keyboard,:focus-visible matches the focused element [1]. If the user interacts via a pointing device, it typically does not match on elements that do not require text input (like buttons) [1]. 2. Programmatic Focus (element.focus): When focus is moved programmatically, the behavior of:focus-visible depends on the context [3][4]. - Initial focus (e.g., page load or autofocus): Browsers typically trigger:focus-visible by default because there is no prior "modality" context [4]. - Focus transfer: If an element currently matches:focus-visible (e.g., the user is already navigating via keyboard), moving focus programmatically to a new element will often cause the new element to also match:focus-visible [3][4]. Conversely, if the element does not match, the new element typically will not [3][4]. 3. Forcing Visibility: Because browser heuristics for programmatic focus can sometimes lead to inconsistent results for developers, the focus method has been extended in many modern environments to accept an options object that includes a focusVisible property [5][6]. Example: element.focus({ focusVisible: true }); Setting focusVisible: true explicitly instructs the browser to show the focus indicator and ensures:focus-visible matches, regardless of the current inferred input modality [5][6].
Citations:
Use a focus style that always appears on the error heading.
Because this heading is focused in
useEffect,focus-visible:can be skipped after pointer-driven failures. Switch these utilities tofocus:or apply an explicit focused state so recovery focus is always visible.🤖 Prompt for AI Agents