🎨 Palette: [접근성] Date Range Picker 프리셋 버튼 키보드 포커스 스타일 추가

[seonghobae]

💡 What:
DateRangePicker 컴포넌트의 프리셋 선택 버튼(7d, 30d, 90d 등)에 키보드 포커스를 시각적으로 나타내는 Tailwind 클래스를 추가했습니다.

🎯 Why:
기존 프리셋 버튼들은 기본 HTML <button> 태그를 사용하면서 커스텀 focus-visible 스타일이 누락되어 있었습니다. 이로 인해 마우스 호버(hover) 시에는 피드백이 제공되지만, 탭(Tab) 키를 이용한 키보드 내비게이션 사용 시에는 현재 포커스된 요소를 알 수 없어 접근성 및 사용성이 떨어지는 문제가 있었습니다.

📸 Before/After:

• Before: 키보드로 탭 이동 시, 버튼에 어떤 시각적 변화도 없어 포커스 위치를 식별할 수 없음.
• After: 키보드로 탭 이동 시, 버튼 테두리에 브랜드 색상의 포커스 링(파란색 계열)이 선명하게 표시되어 현재 선택된 프리셋을 명확히 인지할 수 있음.

♿ Accessibility:
focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-1 focus-visible:ring-offset-card 클래스를 적용하여 마우스 클릭 시에는 포커스 링이 생기지 않도록 하면서, 키보드 사용자에게만 명확한 시각적 피드백을 제공하도록 접근성을 향상시켰습니다.

---

(또한 향후 개발에 참고할 수 있도록 .Jules/palette.md 파일에 기본 HTML <button> 엘리먼트 사용 시 focus-visible 스타일 누락 패턴에 대한 학습 내용을 한글로 기록하였습니다.)

---

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

[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.

[github-actions]

Pull request overview

OpenCode cannot approve yet because required coverage evidence did not pass.

Review outcome

1. HIGH .github/workflows/opencode-review.yml:1 - Coverage evidence did not prove required test/docstring evidence

• Problem: The required coverage-evidence job result was failure, so OpenCode cannot establish approval sufficiency for this head.

• Root cause: Automated approval is only valid when the same-head coverage-evidence job proves supported repository test suites passed and configured docstring gates passed or were advisory, or reports not applicable because no supported source files or package manifests exist. Missing, failed, skipped, unavailable, or unsupported-tooling test evidence is a blocker.

• Fix: Install or configure the repository test/docstring evidence tooling when source files or package manifests exist, rerun the current-head coverage-evidence job, and approve only after it reports success with required evidence or explicit no-source not-applicable evidence.

• Regression test: Keep the approval branch checking needs.coverage-evidence.result == success before posting APPROVE, and publish REQUEST_CHANGES when coverage-evidence blocker states such as cancelled, skipped, failed, unsupported-tooling, or below-100 evidence are present.

• Result: REQUEST_CHANGES

• Reason: coverage-evidence result was failure, so required test/docstring evidence was not proven for current head 4c5fdd83ef43d7217fce1f4623d3a03c45ea1ca8.

• Head SHA: 4c5fdd83ef43d7217fce1f4623d3a03c45ea1ca8

• Workflow run: 28720352933

• Workflow attempt: 1

Coverage evidence

Coverage Evidence

• Head SHA: 4c5fdd83ef43d7217fce1f4623d3a03c45ea1ca8
• Required test evidence: supported repository test suites must pass.
• Required docstring evidence: repository-owned docstring gates must pass when configured; otherwise docstring coverage is advisory.

JavaScript/TypeScript dependencies (npm install)

added 110 packages, and audited 111 packages in 6s

38 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

• Result: PASS

JavaScript/TypeScript docstring coverage

• Result: PASS
• Reason: package.json exists, but no check:python-docstrings, docstring:coverage, or docs:coverage script is defined; docstring coverage is advisory.

JavaScript/TypeScript test coverage

• Result: FAIL
• Reason: package.json exists, but no coverage or test script is defined.

Coverage Decision

• Result: FAIL
• Test evidence: not proven passing
• Docstring evidence: not proven passing when configured
• Failure count: 1

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file (2 files)"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file (2 files)"]
  R1 --> V1["required checks"]

Loading

[github-actions]

OpenCode Review Overview

• Head SHA: 4c5fdd83ef43d7217fce1f4623d3a03c45ea1ca8
• Workflow run: 28720352933
• Workflow attempt: 1
• Gate result: REQUEST_CHANGES (approval step)

Pull request overview

OpenCode cannot approve yet because required coverage evidence did not pass.

Review outcome

1. HIGH .github/workflows/opencode-review.yml:1 - Coverage evidence did not prove required test/docstring evidence

• Problem: The required coverage-evidence job result was failure, so OpenCode cannot establish approval sufficiency for this head.

• Root cause: Automated approval is only valid when the same-head coverage-evidence job proves supported repository test suites passed and configured docstring gates passed or were advisory, or reports not applicable because no supported source files or package manifests exist. Missing, failed, skipped, unavailable, or unsupported-tooling test evidence is a blocker.

• Fix: Install or configure the repository test/docstring evidence tooling when source files or package manifests exist, rerun the current-head coverage-evidence job, and approve only after it reports success with required evidence or explicit no-source not-applicable evidence.

• Regression test: Keep the approval branch checking needs.coverage-evidence.result == success before posting APPROVE, and publish REQUEST_CHANGES when coverage-evidence blocker states such as cancelled, skipped, failed, unsupported-tooling, or below-100 evidence are present.

• Result: REQUEST_CHANGES

• Reason: coverage-evidence result was failure, so required test/docstring evidence was not proven for current head 4c5fdd83ef43d7217fce1f4623d3a03c45ea1ca8.

• Head SHA: 4c5fdd83ef43d7217fce1f4623d3a03c45ea1ca8

• Workflow run: 28720352933

• Workflow attempt: 1

Coverage evidence

Coverage Evidence

• Head SHA: 4c5fdd83ef43d7217fce1f4623d3a03c45ea1ca8
• Required test evidence: supported repository test suites must pass.
• Required docstring evidence: repository-owned docstring gates must pass when configured; otherwise docstring coverage is advisory.

JavaScript/TypeScript dependencies (npm install)

added 110 packages, and audited 111 packages in 6s

38 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

• Result: PASS

JavaScript/TypeScript docstring coverage

• Result: PASS
• Reason: package.json exists, but no check:python-docstrings, docstring:coverage, or docs:coverage script is defined; docstring coverage is advisory.

JavaScript/TypeScript test coverage

• Result: FAIL
• Reason: package.json exists, but no coverage or test script is defined.

Coverage Decision

• Result: FAIL
• Test evidence: not proven passing
• Docstring evidence: not proven passing when configured
• Failure count: 1

Changed-File Evidence Map

flowchart LR
  PR["PR changed files"] --> Evidence["OpenCode bounded evidence"]
  Evidence --> S1["Changed file (2 files)"]
  S1 --> I1["repository behavior"]
  I1 --> R1["Review risk: Changed file (2 files)"]
  R1 --> V1["required checks"]

Loading

[seonghobae]

Closing as superseded during org-wide PR triage. Keeping #213 as the canonical PR for the same overlapping topic: date range picker/accessibility. This PR is stale/conflicted or has review blockers, so retaining one current PR reduces duplicated review and merge conflict work.

[google-labs-jules]

Closing as superseded during org-wide PR triage. Keeping #213 as the canonical PR for the same overlapping topic: date range picker/accessibility. This PR is stale/conflicted or has review blockers, so retaining one current PR reduces duplicated review and merge conflict work.

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