Skip to content

「関連する要素や属性」セクションの書式が統一されていない #319

Open

Description

@nishimotz

概要

テストケースの末尾にある「関連する要素や属性」セクションの書式が、ファイルごとにばらばらになっています。現状は機械的に検証できるルールが無く、新しいテストケースを追加する人がどの書式に合わせればよいか判断できない状態です。書式を決めて統一することを提案します。

現状の分類

WAIC-TEST/HTML/*.md のうち、このセクションを持つ 134 件を数えると次のようになります。

  • 区切り文字を使わず 1 項目だけ: 46 件
  • ,(前後に半角スペース)で区切って 1 行: 37 件
  • 読点「、」で区切って 1 行: 33 件
  • ,(空白なし)で区切って 1 行: 9 件
  • 「なし」: 7 件
  • 箇条書き(- ): 1 件
  • 複数行に分けているがリスト記号がない: 1 件

同じ内容でも表記が揺れています。たとえば属性名の後に半角スペースを入れるかどうかが混在しています。

  • WAIC-TEST-0004-01: img 要素 , map要素 , usemap属性, alt 属性(「map要素」「usemap属性」にスペースなし)
  • WAIC-TEST-0004-02: img 要素 , map 要素 , usemap 属性, alt 属性(同じテストの別事例でスペースあり)

0004-01 と 0004-02 は同じ達成方法の事例 1 と事例 2 なので、並べて読むと差異が目立ちます。同種の「要素名に半角スペースを入れない」表記は、29 ファイルに含まれています。

文末の扱いも揺れています。末尾に句点「。」を付けているのは WAIC-TEST-0031-02 の 1 件だけで、残りは句点なしです。

  • WAIC-TEST-0031-02: role="tree" をもつ ul 要素、role="treeitem" をもつ li 要素、role="group" をもつ ul 要素。

区切り文字と並べ方も、0004-01 の usemap属性, alt 属性 のように、同じ行の中で「カンマ+空白なし」と「カンマ+空白あり」が混ざっている例があります。

複数項目を並べると表示が崩れる例

複数行に分けて書いているのは WAIC-TEST-0003-01 と WAIC-TEST-0057-02 の 2 件だけです。0003-01 は - による箇条書き、0057-02 はリスト記号なしの複数行です。

0057-02 は各行の末尾に半角スペース 2 個(Markdown のハード改行)が無いため、GitHub Pages で表示すると改行が無視され、6 項目が 1 行につながって表示されます。ソース上は 6 行でも、閲覧者には横並びの羅列として見えています。

role="slider" aria-labelledby aria-valuemin aria-valuemax aria-valuenow tabindex

0003-01 が箇条書きを選んでいるのは、この潰れを避けるためだと考えられます。なお 0003-01 も、箇条書きそのものは正しく表示されますが、各行末にハード改行はありません。

影響範囲

このセクションを機械的に読み取っているツールは、リポジトリ内には見当たりません(.github/workflows/makeindex.py は「テストのタイトル」だけを拾い、README.md を生成しています)。したがって、書式を変えても README.md の生成には影響しません。変わるのは GitHub Pages での見た目と、記述の一貫性です。

これは #226「テスト手順の書式を揃える」で扱われた「見出し」の統一とは別の話です。#226 は諸熊さんのテスト支援ツールが見出し文字列をマッチングするために見出し表記を揃えるという目的で、本 issue が対象とするのは見出しではなく本文の書式です。

提案

次のいずれかを決めたうえで、機械的に適用できる範囲で統一することを提案します。文言の修正ではなく書式の修正なので、内容の再検討は不要だと考えています。

1 項目だけの場合も複数項目の場合も、- による箇条書きにする案を第一候補とします。理由は、複数項目のときに表示が崩れないこと、項目の追加や削除がしやすいこと、順序を持たない列挙であることが読み手に伝わることです。前例として WAIC-TEST-0003-01 があります。

次に、属性名の半角スペースは「要素名・属性名に半角スペースを入れない」(img要素、title属性)か「入れる」(img 要素、title 属性)のどちらかに寄せます。現状は「入れる」ほうが多いので、そちらに寄せるのが変更量は少なくなります。

末尾の句点は付けない方向で統一するのが自然です。134 件中 133 件が句点なしです。

補足

tabindex のように ARIA のステート・プロパティではなくホスト言語(HTML)の属性が混ざる場合があります。このセクションの見出しは「関連する要素や属性」なので厳密には誤りではありませんが、区別を付けて書くかどうかも併せて決められるとよいと思います。

やること

  • 書式を決める(箇条書きにするか、1 行の列挙を維持するか)
  • 属性名・要素名の半角スペースの扱いを決める
  • 末尾の句点の扱いを決める
  • 決めた書式を既存ファイルに適用する
  • 新しいテストケース追加時に見落とさないようにする方法を検討する(Markdownlint では書式を検知できないため、レビュー時のチェック項目にするなど)

参考

作業中の PR #318(WAIC-TEST-0057-02 の追加)で、この書式の問題に気付いたのがきっかけです。PR のスコープを超えるため、issue として分離しました。

Activity

  1. mehm8128 commented on Oct 7, 2026

    @mehm8128
    Member

    どこまでやるかという問題はありますが、Markdownlintのカスタムルールで独自ルールを作って機械的に検知することは可能そうです

  2. mehm8128 commented on Oct 12, 2026

    @mehm8128
    Member

    以下の3つの点から、もう少し機械的に記載内容を決められるようにするか、セクション自体消してしまうという案もあるのかなと思いました

    • 「type=”text” を持つ input 要素」みたいなケースもありそう: https://waic.github.io/as_test/WAIC-TEST/HTML/WAIC-TEST-0012-01.html
      • issue本文に記載の「role="tree" をもつ ul 要素」は「持つ」が平仮名
    • テストコード中からどういう基準で何を「関連する要素や属性」として記載するかが曖昧
    • 「関連する要素や属性」を現状特にどこからも参照していなさそう?
  3. nishimotz commented on Oct 14, 2026

    @nishimotz
    ContributorAuthor
    • テストファイル作成の手順 に、「関連する要素や属性」の選び方が書かれている。(テストコードを確認し、利用している要素、属性を抽出)
    • テクニック集などは由来ではない。
    • as_info ではいま参照、利用されていない。
    • ちゃんと整備したら「HTML要素名、属性名からテストを探す」ナビゲーションが as_info で可能になり、テストデータを使った自動チェックツールなどへの応用が期待できる
    • テストコードから「関連する要素や属性の自動抽出」をするアプローチも可能だが、テスト作成者が論点を絞って挙げることで、ダミーコードの影響を回避できる。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions