CodeForPhilly / CodeForPhilly/codeforphilly-ng
Card heading level should be a prop (TagDetail renders section h2 followed by ProjectCard h2s)
- 主要言語
- TypeScript
- スター
- 1
- フォーク
- 1
- 平均マージ
- 5日 3時間
- マージ済み PR(30日)
- 9
説明
## Context
The shared cards render a fixed heading level: `ProjectCard` renders `h2`, `PersonCard` and `HelpWantedCard` render `h3`. PR #157 worked around this on the index screens by adding sr-only `
Results
` headings above the `h3` cards rather than changing the cards, because each card is also used in a second context where its fixed level is correct.## Problem
The fixed level is still wrong somewhere. `TagDetail` renders a section `
` ("Projects", "Help wanted", "Members") and then a list of `ProjectCard`s, each of which contributes another `h2` — so the section heading and every card title sit at the same level, and the document outline reads as a flat run of h2s instead of section → items. Any future screen that composes cards under a section heading hits the same problem.
## Proposal
Give the three cards a `headingLevel` prop (`2 | 3 | 4`, defaulting to today's level so nothing changes at existing call sites), rendered via a small `Heading` helper or `createElement(`h${level}`)`. Then `TagDetail` passes `headingLevel={3}` to `ProjectCard`, and the sr-only "Results" headings on `PeopleIndex` / `HelpWantedIndex` can be revisited (the cards could render `h2` directly there).
Related: issue #156 (CardTitle semantics) covers the design-decision side of card headings.
Deferred from `plans/a11y-mechanical.md` (PR #157).
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
Locate the named ProjectCard, PersonCard, HelpWantedCard, TagDetail, PeopleIndex, and HelpWantedIndex entry points, then read plans/a11y-mechanical.md and issue #156 for the heading context. Verify the existing heading levels and call sites first; done means the cards accept the proposed defaults, TagDetail produces section-to-item headings, and the index behavior is checked without breaking existing uses.
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- typescript
- 領域
- accessibility, frontend
- issue の種類
- 機能追加
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 活発
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 68/100