Wikipedia‐ノート:アクセシビリティ

過去ログ等[編集]

英語版の翻訳による内容充実[編集]

2006年2月24日 (金) 17:40 の立項以来ほとんど加筆がされていない状況なので、英語版en:Wikipedia:Accessibilityの翻訳によって本項を充実させたいと思います。反対がなければWikipedia:ウィキプロジェクト プロジェクト関連文書/翻訳依頼に依頼を提出したいと思います。ご意見をお寄せください。--模様砂漠2 2009年7月13日 (月) 11:06 (UTC)[返信]

一週間反対意見がありませんでしたので、翻訳依頼を行います。--模様砂漠2 2009年7月20日 (月) 11:28 (UTC)[返信]

翻訳と加筆を行ないました。一部、他のスタイルマニュアルと重複する部分があったので、そこは訳しませんでした。また、一部未訳となっています。これは英語の問題よりも、私が日本語スクリーンリーダについて無知だったためです。詳しい方の加筆をお願いします。--Yghwtrrl 2009年11月10日 (火) 05:00 (UTC)[返信]

色の濫用規制と分割・正式化の提案[編集]

情報 分割・正式化案を作成しましたので、Wikipedia‐ノート:色の使用に移行します。--氷鷺会話2013年6月29日 (土) 07:24 (UTC)[返信]

特にナビゲーション・テンプレートに顕著ですが、読みやすさに(そして大抵はデザイン的にも)問題がある背景色と文字色の組み合わせや、派手な原色の濫用が目立ちます。そこで

  1. ナビゲーション・テンプレートおよびインフォボックスの背景色や文字色の指定について、以下のような制限をWikipedia:アクセシビリティ#色に追加する。
    • 案1. 色指定は禁止
    • 案2. 英語版に準じる。ナビゲーション・テンプレートの色指定は禁止、インフォボックスはWikipedia:Infobox coloursを適用し分野ごとに統一する。
    • 案3. 背景色に彩度・明度による制限を設け、文字色は黒のみとする。(例:彩度20%以下・明度95%以上)、
  2. その上でWikipedia:アクセシビリティ#色を「Wikipedia:色の使用は控えめに」または「Wikipedia:アクセシビリティ/色」に(他に適切なページ名があればそれに)分割し、先行して正式化する。

ことを提案します。この「Wikipedia:アクセシビリティ」ごと正式化できればそれが望ましいのですが、現状では(個人的には)まだまだ正式化できる状態ではない――少なからず問題があると思いますので。将来的にこちらが正式化した際には再度統合すれば良いでしょう。--氷鷺会話) 2013年1月23日 (水) 15:23 (UTC) 一部修正[1]。--氷鷺会話2013年1月25日 (金) 22:14 (UTC)[返信]

質問 確認したいのですが、分割する部分はWikipedia:アクセシビリティ#色の節を、ということでしょうか?どこをどう分割して正式化するのかあまり明確でないので、素案などがあれば議論しやすくなるかと思います。--青子守歌会話/履歴 2013年1月25日 (金) 04:49 (UTC)[返信]
コメント 訂正しました。#色の節です。--氷鷺会話2013年1月25日 (金) 22:14 (UTC)[返信]
コメント ちなみにこれは、タイトル(title)部分の色についての議論で宜しいのでしょうか。案3. ベースが宜しいのではと思います。
個人的には背景の濃さに合わせて「黒または白」の方がよいのではと。案3そのものですと、黒とかぶる濃色(紺色など)の背景色は使用不可能となるのですかね。 --Benzoyl会話2013年6月17日 (月) 04:00 (UTC)[返信]
質問 案2. についてです。英語版では、「ナビゲーション・テンプレートの色指定は禁止されている」のでしょうか。
en:Template:National sports teams of Serbia」のようなものもございますようですが。--Benzoyl会話2013年6月17日 (月) 04:00 (UTC)[返信]
コメント 日本語版ほど悪質で稚拙な「色遊び」が深刻ではない印象はありますね。では「英語版に準じる」はインフォボックスのほうにかかる修飾語ということで理解してください。とりあえず、コーポレートカラーやイメージカラーの「お遊び」が悪質すぎるのでそれを阻止するのが目的ですから。--氷鷺会話2013年6月21日 (金) 17:47 (UTC)[返信]
コメント どうしてこの色を?というのや、使ってはいけない色合いとかありそうですが、チームカラー等かけがえのない配色はあるのかと。例えば「{{San Francisco Giants}}」({{BaseballColor}})のようなキツめのものは、彩度を下げたらよいのではと思います。全面禁止はよくないかと。--Benzoyl会話) 2013年6月26日 (水) 03:06 (UTC)--Benzoyl会話2013年6月26日 (水) 03:06 (UTC)[返信]
コメント 「チームカラー等かけがえのない配色」は他所でやってください。ファンクラブでもなければサポーターグループでもないのですよ。「かけがえのない配色」など存在しません。--氷鷺会話2013年6月26日 (水) 14:45 (UTC)[返信]
ほう、諸外国のウィキペディアでは導入していても、日本語版では色狩りという、頑なにガラパゴス独自路線を目指されたいというお考えということで宜しいのでしょうかね。--Benzoyl会話2013年6月27日 (木) 00:42 (UTC)[返信]
それぞれの言語版が独自に動いているのですから、他言語版を真似する理由はどこにもありません。--氷鷺会話) 2013年6月29日 (土) 06:45 (UTC) 氷鷺氏のコメントを一部コメントアウト、理由はソースに記載。--Y717会話2013年8月13日 (火) 16:52 (UTC)[返信]
お忙しい中、貴重な暴言、誠に有難うございました…。--Benzoyl会話2013年6月29日 (土) 11:14 (UTC)[返信]
情報 「{{Color box2}}」を基に、「{{Bcfc}}」を作成いたしました。
配色研究は、別のところに新たに設置してやった方がいいのですかね。とりあえずこんな感じで。
Navbox」のタイトル色のデフォルトは、「#ccccff」で合ってるでしょうか。 --Benzoyl会話2013年6月18日 (火) 04:42 (UTC)[返信]
red blue green yellow white black
blue green yellow white black
red green yellow white black
red blue yellow white black
red blue green white black
red blue green yellow black
red blue green yellow white
#ccf red blue green yellow white black
コメント グレースケール変換の方法は、色々な種類あるのでしょうかね。NTSC(系)加重平均法など。すみません、よく分かりませんでした。カラーユニバーサルデザインも参考。--Benzoyl会話2013年6月20日 (木) 00:32 (UTC)[返信]

原色などの使用状況[編集]

背景 title group テンプレ
re #FF6 Template:ルパン三世編集 / ノート / リンク元 / 履歴 / ログ
多色 Template:たまむすび編集 / ノート / リンク元 / 履歴 / ログ
#fe0 black Template:はねるのトびら編集 / ノート / リンク元 / 履歴 / ログ
re white Template:爆笑レッドシアター編集 / ノート / リンク元 / 履歴 / ログ
re yellow Template:爆笑レッドカーペット編集 / ノート / リンク元 / 履歴 / ログ
re #0645AD white Template:西部警察編集 / ノート / リンク元 / 履歴 / ログ
re black Template:StreetFighter編集 / ノート / リンク元 / 履歴 / ログ
ye red Template:お笑いスター誕生!!編集 / ノート / リンク元 / 履歴 / ログ
red Template:鉄拳シリーズ編集 / ノート / リンク元 / 履歴 / ログ
多色 Template:埼玉西武ライオンズ及びその前身球団歴代オーナー編集 / ノート / リンク元 / 履歴 / ログ
#ED1A3D blue red Template:SMAP☆がんばりますっ!!編集 / ノート / リンク元 / 履歴 / ログ
Gold red Template:アンタッチャブル編集 / ノート / リンク元 / 履歴 / ログ
re Khaki Template:ロンドンブーツ1号2号編集 / ノート / リンク元 / 履歴 / ログ
white red Template:Jリーグベストイレブン (FW)編集 / ノート / リンク元 / 履歴 / ログ
white red Template:Jリーグベストイレブン (MF)編集 / ノート / リンク元 / 履歴 / ログ
white red Template:Jリーグベストイレブン (DF)編集 / ノート / リンク元 / 履歴 / ログ
white red Template:Jリーグベストイレブン (GK)編集 / ノート / リンク元 / 履歴 / ログ
ye OrangeRed #0645AD Template:リッジレーサー編集 / ノート / リンク元 / 履歴 / ログ
ye #0645AD #0645AD Template:大脳基底核編集 / ノート / リンク元 / 履歴 / ログ
ye #0645AD #0645AD Template:脊髄編集 / ノート / リンク元 / 履歴 / ログ
#7445aa yellow purple Template:魔界戦記ディスガイアシリーズ編集 / ノート / リンク元 / 履歴 / ログ
#950306 gold gold Template:早稲田大学総長編集 / ノート / リンク元 / 履歴 / ログ
ye #0645AD #0645AD Template:終脳編集 / ノート / リンク元 / 履歴 / ログ
ye #0645AD #0645AD Template:太陽編集 / ノート / リンク元 / 履歴 / ログ
多色 Template:宝塚歌劇団編集 / ノート / リンク元 / 履歴 / ログ
#f090f0 #0645AD black Template:ゆるゆり編集 / ノート / リンク元 / 履歴 / ログ
ye black Template:柏レイソルのメンバー編集 / ノート / リンク元 / 履歴 / ログ
ye black Template:柏レイソル及びその前身チーム歴代監督編集 / ノート / リンク元 / 履歴 / ログ
黄に緑囲み Template:栃木SCのメンバー編集 / ノート / リンク元 / 履歴 / ログ
re yellow Template:名古屋グランパスのメンバー編集 / ノート / リンク元 / 履歴 / ログ
#0cc yellow black Template:プロレスリングWAVE編集 / ノート / リンク元 / 履歴 / ログ
#019800 orange black Template:学校法人ワタナベ学園編集 / ノート / リンク元 / 履歴 / ログ
白に赤囲み Template:FC刈谷のメンバー編集 / ノート / リンク元 / 履歴 / ログ
赤に黒囲み Template:デッツォーラ島根のメンバー編集 / ノート / リンク元 / 履歴 / ログ
re #0645AD black Template:彩雲国物語編集 / ノート / リンク元 / 履歴 / ログ
blue white Template:日本サッカー殿堂編集 / ノート / リンク元 / 履歴 / ログ
blue white Template:水戸ホーリーホックのメンバー編集 / ノート / リンク元 / 履歴 / ログ
ye blue Template:Team Blue Mountain編集 / ノート / リンク元 / 履歴 / ログ
blue white Template:BMWザウバーF1編集 / ノート / リンク元 / 履歴 / ログ
DeepPink Blue Template:ナムコのテニスゲーム編集 / ノート / リンク元 / 履歴 / ログ
white Template:鉄腕アトム編集 / ノート / リンク元 / 履歴 / ログ
青囲み Template:日本フットボールリーグ新人王編集 / ノート / リンク元 / 履歴 / ログ
トリコ囲み Template:サッカーロシア代表歴代監督編集 / ノート / リンク元 / 履歴 / ログ
Tomato black Template:所ジョージ編集 / ノート / リンク元 / 履歴 / ログ
white red Template:Jリーグ主将編集 / ノート / リンク元 / 履歴 / ログ
white red Template:Jリーグ監督編集 / ノート / リンク元 / 履歴 / ログ
#ccc red Template:ウルトラシリーズ出演者編集 / ノート / リンク元 / 履歴 / ログ
re white black Template:日テレジェニック編集 / ノート / リンク元 / 履歴 / ログ
gr greenyellow Template:ギャラクシアン編集 / ノート / リンク元 / 履歴 / ログ
gr white white Template:デビルマン編集 / ノート / リンク元 / 履歴 / ログ
green Template:日本未来の党編集 / ノート / リンク元 / 履歴 / ログ
gr white Template:VONDS市原のメンバー編集 / ノート / リンク元 / 履歴 / ログ
gr red Template:学校法人常葉学園編集 / ノート / リンク元 / 履歴 / ログ
LightSalmon SeaGreen Template:ウッチャンナンチャン編集 / ノート / リンク元 / 履歴 / ログ
黄囲み Template:タイ国王編集 / ノート / リンク元 / 履歴 / ログ
多色 Template:創価学会編集 / ノート / リンク元 / 履歴 / ログ
white Template:日本アイ・ビー・エム編集 / ノート / リンク元 / 履歴 / ログ
pink Template:ブシロード編集 / ノート / リンク元 / 履歴 / ログ
pink Template:OMIASHI編集 / ノート / リンク元 / 履歴 / ログ
white Template:政治指導者の遺体保存施設編集 / ノート / リンク元 / 履歴 / ログ
white Template:ドミニコ会編集 / ノート / リンク元 / 履歴 / ログ
white black Template:BlackBerry編集 / ノート / リンク元 / 履歴 / ログ
re black Template:TEAM WESTWIND編集 / ノート / リンク元 / 履歴 / ログ
white black Template:Acid Black Cherry編集 / ノート / リンク元 / 履歴 / ログ
re white Template:ASAI RED ROSE編集 / ノート / リンク元 / 履歴 / ログ
red Template:世にも奇妙な物語編集 / ノート / リンク元 / 履歴 / ログ
re white black Template:学校法人千代田学園 (大阪府)編集 / ノート / リンク元 / 履歴 / ログ
re black #0645AD Template:北朝鮮の歌曲編集 / ノート / リンク元 / 履歴 / ログ
re white Template:アメリカ三冠馬編集 / ノート / リンク元 / 履歴 / ログ
re #0645AD black Template:TIM編集 / ノート / リンク元 / 履歴 / ログ
その他

{{オレたちひょうきん族}}、{{ポンキッキシリーズ}}

疲弊したため、ひとまず中途挫折。--Benzoyl会話) 2013年6月28日 (金) 09:23 (UTC) 続行差し替え--Benzoyl会話) 2013年6月28日 (金) 13:26 (UTC) --Benzoyl会話) 2013年6月28日 (金) 13:32 (UTC) --Benzoyl会話) 2013年6月28日 (金) 13:33 (UTC) --Benzoyl会話) 2013年6月28日 (金) 13:40 (UTC) --Benzoyl会話2013年7月12日 (金) 01:15 (UTC)[返信]

原色以外の使用状況[編集]

背景 title group テンプレ
#EEDD82 #0645AD Template:アカデミー賞史編集 / ノート / リンク元 / 履歴 / ログ
その他

en:Portal:Japanの色合い(#FF5959)

--Benzoyl会話) 2013年7月6日 (土) 09:52 (UTC)--Benzoyl会話2013年7月19日 (金) 21:52 (UTC)[返信]

感想欄[編集]

問題な?配色例[編集]

--Benzoyl会話2013年7月2日 (火) 12:52 (UTC)[返信]

最小限?の基本色での比較[編集]

セーフカラーから[編集]

300 330 0 30 60 90 120 150 180 210 240 270
#606 #603 #600 #630 #660 #360 #060 #063 #066 #036 #006 #306
#c0c #c06 #c00 #c60 #cc0 #6c0 #0c0 #0c6 #0cc #06c #00c #60c
#939 #936 #933 #963 #993 #693 #393 #396 #399 #369 #339 #639
#f3f #f39 #f33 #f93 #ff3 #9f3 #3f3 #3f9 #3ff #39f #33f #93f
#c6c #c69 #c66 #c96 #cc6 #9c6 #6c6 #6c9 #6cc #69c #66c #96c
#f9f #f9c #f99 #fc9 #ff9 #cf9 #9f9 #9fc #9ff #9cf #99f #c9f

--Benzoyl会話) 2013年7月4日 (木) 02:05 (UTC) あえて目が疲れる原色を排除し、セーフカラー抜粋に差し替え。--Benzoyl会話2013年7月6日 (土) 10:48 (UTC)[返信]

ショートカットの取消[編集]

WP:CLICKHEREなるショートカットを除去しました。この編集を行った利用者: 240F:77:BE3:1:857A:D311:FCE3:691さんはClick hereというリダイレクト(ここをクリックへ)を作成し、さらに[[WP:CLICKHERE]]を作成していますが、有用でないと考えます。--柒月例祭会話2015年1月5日 (月) 00:59 (UTC)[返信]

コメント IPアドレスは変わっていますが、本ショートカット製作者です。本ショートカットはWikipediaに関する「ここをクリック」に関する規定を承知していないユーザが「一覧を見るにはここをクリック」みたいな文書(&表)を記事に埋め込んだときを想定→rvなどの際の要約記事に使用することを想定して制作しました。[[WP:CLICKHERE]]Wikipedia:ウィキペディアへの自己言及#印刷版に配慮するへのショートカットでも構いません。 --240F:77:BE3:1:4920:4938:BD48:4E3D 2015年1月8日 (木) 11:14 (UTC)[返信]
意図はわかりました。が、IPさんがおっしゃる“想定”がどれぐらいあるのか、疑問です。絶対にゼロだとは言いませんし、英語版絶対主義というわけでもないのですが、あえて英語版と同名のショートカットで別のところへ飛ばすようにしなければならないほどに、その必要性があるようには思いません。IPさんが、英語版と同じように印刷版に配慮するへのショートカットでもよい、とおっしゃっていただけるのであれば、それがよいと考えます。
ところで、利用者:240F:77:BE3:1:857A:D311:FCE3:691さん=利用者:240F:77:BE3:1:4920:4938:BD48:4E3Dさんは、利用者:240F:77:BE3:1:5C9A:D73C:5DCE:5723さんとは同じ方ですか?「240F:77:BE3:1:」までは一緒なので、どうなのかなあ?、と思ったのですが・・・。これは強制ではないのですが、IPが一日に何度も変わるようであれば、なかなか対話をしていくのも難しいものですから、Help:ログインでも「説明責任の観点から推奨」されていますように、アカウントをご取得いただくことはできないでしょうか?--柒月例祭会話2015年1月11日 (日) 13:59 (UTC)[返信]
貴方のコメントを拝見いたしました。前2IPと同じ者です。("240F:77:BE3:1:"が一致することからもお気づきのはず)アカウントの件ですが、1か月間悩んでおりますが、適切なユーザネームを思いつくことが出来かねております。既存の活動者と同じor類似がNGだとか、「最近の更新」に時々現れてくる"{{usernameblock}}"とか、色々な制約もあり、なにを用いればよいのかわからないのが現実です。(このことは、IPユーザのまま活動を続ける可能性を否定しておりません)

本題に戻りますが、柒月例祭さんが「IPさんが、英語版と同じように印刷版に配慮するへのショートカットでもよい、とおっしゃっていただけるのであれば、それがよいと考えます。」とおっしゃっている以上、そちらへのSCにしても問題ないと思います。(追記: 「124.211.186.111」となってしまいましたが、これははっきりとした確証は持てませんが、恐らくKDDIの都合でIPv6のアドレスが変化する最中に一時的にIPv4のアドレスになったものだと思われます。「プレビュー」のときは"240F:77:BE3:1:~"と表示されておりました) --124.211.186.111 2015年1月13日 (火) 14:08 (UTC)[返信]

この文書の修正点[編集]

さて、Wikipedia:色の使用が正式にガイドライン化しました。議論に参加してくださった皆様、ありがとうございました。さて、ここからは、Wikipedia:アクセシビリティのガイドライン化について議論していきたいと思います。ネイさんによると、このページはまだ修正が必要、とのことでした。ネイさんはもちろん、他の皆様からもこの草案の改善点を募集したいと思います。--新世紀のウィキぺディア会話2017年4月2日 (日) 12:22 (UTC)[返信]

報告 本件に対して、議論活性化のためのコメント依頼を提出しました。--新世紀のウィキぺディア会話2017年4月2日 (日) 12:33 (UTC)[返信]

コメント依頼を提出していただきありがとうございます。今の草案は2009年時点の英語版に基づくものなので、まずは土台としてen:Wikipedia:Manual of Style/Accessibilityの最新版を再び訳出し、現在の草案とすり合わせるつもりです。わたしの利用者ページで草稿を作成し、問題がなければ数日後にこちらに転記したいと思います。なお、現在の草案でも問題ないとの合意が得られた場合は翻訳を中止します。--ネイ会話2017年4月3日 (月) 03:50 (UTC)[返信]

報告 まずはen:Wikipedia:Alternative text for images利用者:ネイ/Wikipedia:画像の代替テキストにて訳しました。ご自由に編集してください。1週間ほど反対がなければWikipedia名前空間に移したいと思います。--ネイ会話2017年4月4日 (火) 16:03 (UTC)[返信]
誤字(文体の不統一)•脱字がありましたので修正しておきました。Wikipedia名前空間への移動に 賛成 します。ただ、日本語版では代替テキストが指定されていない画像が大多数だと思いますので、画像には代替テキストを付けるよう告知する必要がありそうです。--新世紀のウィキぺディア会話2017年4月5日 (水) 00:41 (UTC)[返信]
修正していただきありがとうございます。代替テキストの告知についてですが、代替テキストを付けること自体がガイドラインになっていない(はず。見落としがありましたらご指摘ください)ので今は私論としての告知しかできず、あまり役に立たないと思います。代替テキストを付けることはこのページで推奨されているので、ガイドライン化に漕ぎ着けたら告知しましょう。おそらくはスタイルマニュアルを改定して誘導することになるでしょう。--ネイ会話2017年4月5日 (水) 08:50 (UTC)[返信]
了解しました。--新世紀のウィキぺディア会話2017年4月5日 (水) 08:55 (UTC)[返信]

コメント どうやら、一から再翻訳する必要はなさそうです。草案の変更点に下記を提案します。まだまだ草案のままなので、上記の移動提案と同時に実行したいと思います。

  1. 「文章」の節の3番目において、「♥(ハートマーク)のような読めない文字を使わない。その代わり、代替テキストつきの画像を使用してください。なお、このようなシンボルの一部には{{Dagger}}のように代替テキストつきの画像を表示させるテンプレートが存在する。Category:画像挿入テンプレートを参照してください。」を追加する。これは「リンク」の節の4番目を置換するものです。
  2. 「文章」の節の4番目において、{{Abbr}}を例外とする。
  3. 「外国語」の節を「文章」の節の中に移動する。
  4. 「画像」の節の5番目において、「これはモバイル用のサイトでの表示と、スクリーンリーダーが画像の代替テキストとキャプションを読み上げるタイミングに影響するからです。」を追加する。
  5. 「動画と音声」の節について。まず、WCAG 2.0に「GIF動画の長さが5秒を超えないこと」「再生、一時停止、停止の機能をつけるべき」という規定があるため、5秒以上のGIF動画は動画ファイルに変換すべきという規定を追加すること。次に、1秒間に3回以上点滅する動画は発作を引き起こす恐れがある(WCAG 2.0より)ため、これを禁止する。そして、動画と音声については字幕とサブタイトルをつけることを推奨する。また字幕をつけることの説明は英語版に倣ってウィキメディア・コモンズへのリンクにする。この辺りはこちらが決着した後、Help:音声・動画の作成と利用にでも追加しましょうか。
  6. Wikipedia:画像の代替テキストWikipedia:ディスレクシアの読者へのリンクを張る。--ネイ会話2017年4月6日 (木) 15:24 (UTC)[返信]
それでよいでしょう。本当は{{Abbr}}も廃止したほうが良いのかもしれませんが、日本語版を含め93言語版にある上、参照読み込み数が7000件近くあるので、やむを得ないでしょう。--新世紀のウィキぺディア会話2017年4月7日 (金) 06:40 (UTC)[返信]

コメントおつかれさまです。アクセシビリティについては、WCAG2.0が体系的で網羅的であるでしょうから、基本的にはそれに則っていけばいいでしょうね。ただ、WCAG2.0の基準を、どこまでウィキペディア日本語版でも求めていくかは実際的な難しさと照らし合わせるべきでしょうね。基本的には「推奨」であって、「強制」「禁止」とまでの効力を与えるかどうかは慎重に考える必要があると思います。

  • 私としては、単に「○○すべし」「○○べからず」を列記するのではなく、理由・目的・趣旨・方針・原則を最初に示した上で、実例として具体的説明をするというスタイルにしてほしいなと思います。
  • たとえば例示されている「ハートマーク」がなぜダメなのか。環境によって文字化けするからなのか、「ハート」と代替テキストがあればいいのか、私はよくわからない。こじつけると、WCAG2.0の1.1.1の「非テキストコンテンツ」の「感覚的」ないし「装飾、整形、非表示」に該当するからかな?とか。どこまでが「テキスト」でどこからが「非テキスト」なのか。画像で代替しろというけども、それはそれで画像の寸法指定とフォントサイズとかの問題も考慮に入れる必要があるような気もするし。「ユニコードに対応していないスクリーンリーダー(音声読み上げソフト)」の話は英語圏のことだとされているし、じゃあ日本語圏では実際どうなんだろうとか。日本語版では、日本語圏で普及しているスクリーンリーダーに合わせるべきだろうし、そこらへんはWCAG2.0の3.1では自然言語(当然、日本語版では日本語)に合わせるべきということになっているし。(ここらへんは私はよくわからない。)WCAG 2.0解説書の1.1.11.4.5文字画像WCAG 2.0解説書3.1あたりが関係するのでしょうけれど。。。日本語の音声読み上げソフトというのが、記号や難しい熟語みたいなものを、どの程度意図通り読んでくれるものなんでしょうね。
  • (追記)ハートマークは「読めない」からダメだと言うことになっているのですが、「♥」の記号を「ハート」と「読めない」ひとがどれ位いるのでしょう(読み上げソフトが「読めない」のでしょうか?)。「冶金」のほうがよっぽど読めないだろうと思うんですよね。ハートマークが「読めない」のであれば、それを画像で代替したところでやっぱり読めないでしょう。(画像で代替する理由は、環境依存文字だからということでしょうね。)で、これが「ハートマーク」だとわかったところで、意味がわからなければそれはそれで問題です。「冶金」を「やきん」と読むことがわかっても意味がわからなければどうしようもないのと一緒。そこらへんは、たとえば「∂(偏微分記号)」あたりよりはよっぽど「ハートマーク」のほうが意味(「意味」と「雰囲気・ニュアンス」はちょっと違いますが)が通じるでしょうし。「環境依存文字だからダメですよ」と言ってくれたほうがスッキリすると思うんです。読み上げソフトが「読めない」というのなら、読み上げソフトがどれぐらい「読める」のか(難しい漢字とか)、知りたいところですよねえ。そこらへんはWCAG2.0の3.1と関わりが深いところです。
  • 現在の文書には、部分的・断片的に、HTMLの作法(タグとマークアップ)の話や、スクリーンリーダーの話も盛り込まれています。これらも広い意味ではWCAG2.0が捕捉するだろうとは思いますが、WCAG2.0が2008年のものであるのに対し、HTML5.0のように2016年11月のものもありますから、そこらへんの整合性とかもありますね。
  • WCAG2.0はアクセシビリティに関する文書ですが、その3.1は、「アクセシビリティ」の中だけでまとめるのはなかなか難しい内容だと思います。要するに「日本語を使え、横文字は使うな」(3.1.1-3.1.3)とか、略語の扱い(3.1.4)とか、Wikipedia:表記ガイドと密接に関連しています。3.1.5(中学生でもわかるように)なんかはウィキペディアの根本に影響を与えそうですね。ここらへんは「推奨」「禁止」とかの効力に言及せずに、「考え方を紹介」する程度にとどめたり、それらをサポートするテンプレートや関連文書を紹介する程度まででしょうねえ。
  • 今のところWikipedia:アクセシビリティでは直接言及は少ないのですが、閲覧環境の多様性(ブラウザ、PC、モニターの解像度、個人設定、スマホ)とかは難問だなあと感じます。あちこち眺めると、昔(2003年頃)よりもPCディスプレイの解像度は高くなっているので画像や表組みのサイズは大きめにという議論と、スマホ等での閲覧環境に配慮して小さめにという議論が併存しているようですし。特にスマホ等での利用についての議論・仕様については、我々一般利用者が議論してルールを決めるようなレベルを超えているんじゃないかなあとも思います(スマホ側でなんとかしろよ、とか、財団のほうで決めてくれ、的な。)。
  • まあ話を広げすぎてもアレなので、まずはWCAG2.0の1.1(画像)と1.2(動画・音声)に限定して、とかですかね。(それでも「ハート」の話が、「画像」なのか「テキスト」なのかどっちなのかなあ。)--柒月例祭会話2017年4月13日 (木) 07:13 (UTC)[返信]
コメント 今すぐ返事を書けないので一つだけ。ハートマークがだめなのは読み上げソフトが読めない(スキップされる)からで、画像ならば代替テキストを読み上げるので、そこにハートマークがあるのがわかります。つまり、読み上げソフトでできるだけ内容を失わないようにするためです。代替画像についてはTemplate:Daggerのようなテンプレを想定しています。--ネイ会話2017年4月13日 (木) 07:42 (UTC)[返信]
返信 ありがとうございます。「読み上げソフトが読めない」ことが原因で、その対策として代替画像を使うのであれば、次のような2点のことを考えます。(断言というよりは「こういうのはどうなんだろう?」ぐらいの感じです。)
  • 「読み上げソフトが読める、読めない」の境界線を(ある程度)はっきりしておく必要がありそうだ。
  • 代替画像ではなく、{{読み}}・{{読み仮名}}テンプレートを使用し、「ハート」とする方法でもいいのではないか。画像で代替する場合、読めない文字の数だけ画像を用意して、それを全部知っておく必要があるのに対し、このテンプレートだとなんでもいける。しかもこのテンプレートの場合には、フォントサイズ設定や画像サイズ指定などレイアウトの問題も起きない。ただし、このテンプレートの本来の設計意図・技術的な挙動とはちょっと違う使い方かもしれないのですが。--柒月例祭会話2017年4月13日 (木) 08:35 (UTC)[返信]

コメント 私はスクリーンリーダーの仕様についてはよく分かりません。申し訳ありません。--新世紀のウィキぺディア会話2017年4月13日 (木) 10:37 (UTC)[返信]

  • 正直、私もスクリーンリーダーの仕様だとか、HTML5のことだとか、色々わからないことがあります。WCAG2.0はアクセシビリティの観点からまとめられてはいて、その具体的な中身はウィキペディアの色々な文書と部分的・断片的に対応していたり、ところによっては相反するような内容になっているようです。ウィキペディア内の各文書が必ずしも体系的に作られたものではないので、しかたがないのですが。なんとなく、「決める」前の段階として、あちこち(各文書)から情報を集めてすり合わせる手順が必要だなあと感じます。--柒月例祭会話2017年4月14日 (金) 02:39 (UTC)[返信]

コメントこれ、難しく考えると難しいですね。あらためてWCAG2.0文書に目を通しました。

  • まず、「ガイドライン化」はいったん少し棚上げしませんか。もちろん長期的な目標というか、ゆくゆくはガイドライン化をめざすわけですが、その前段階として、ガイドラインにふさわしい内容にまとめる必要があり、今はまだちょっとそこまで距離があると思います。
  • WCAG2.0の内容に限って言うと、ランクA、AA、AAAの3段階の「適合レベル」があります。もちろんより高いレベルを目指すべきではありますが、現時点ではAにも適合していないでしょう。いきなりAAAを求めるのは無理があります。まずはAの項目だけに絞って議論するとかがいいのかなと思います。(項目によって、とっつきやすい、とっつきにくいがあるのですが。)
  • おおざっぱには、Aは「必須」(方針)、AAはガイドライン、AAAは「できれば」ぐらいの位置づけにするんだろうなとは思います。
  • WCAG2.0に則ると、どうしても「○○は禁止」という内容がいろいろ出てきます。「○○したほうがいい」という条項はいいのですが、「禁止」となると、禁止する理由や根拠がきちんとしている必要があるでしょう。(方針文書でないガイドラインで「禁止」することがどの程度の効力となるのか、ビミョーなところもあると思う。)
  • ランクAに該当するのは、1.1.1、1.2.1、1.2.2、1.2.3、1.3.1、1.3.2、1.3.3、1.4.1、1.4.2、2.1.1、2.1.2、2.2.1、2.2.2、2.3.1、2.4.1、2.4.2、2.4.3、2.4.4、3.1.1、3.2.1、3.2.2、3.3.1、3.3.2、4.1.1、4.1.2です。これを全部例外なくクリアしないと、サイト全体として「レベルA適合」にはならないので、部分的に採用することは(もちろん悪いことではないでしょうけど)全体として結果的にはあまり意味がない。「サイト全体としてランクAをとりましょう」的なコンセンサスがあればいいのですが、そうでないのなら部分的につまみ食いをするような格好になります。そういうつまみ食い方式になったときにどこまで「強制度」を求めるのか、根拠だとかがビミョーかなと。(別にそこまでしなくていいじゃないか、という意見もあるでしょう。)
  • ランクA項目の中には、難易度が高かったり、ウィキペディア日本語版だけで完結できないんじゃないかな?というような項目もあるような気がします。ウィキペディアとしては容易ではなさそうな項目もあります。ウィキペディア(MediaWiki)の仕様そのものに関わるようなことだとか、メディア(画像、動画)類に関することだとか。
  • AA以上の項目については、特に1や3の中には英文を前提としたような項目があって、日本語文にしたときにどうなるのかな?とよくわからない項目もちらほらあります(3.1.2とか。)。
  • 当座の話として、ウィキペディア日本語版は全体としてのA適合水準を目指しましょう、的な大きな合意を形成する、というのを最初にしたほうがいいかなとは思います。そういう方向性自体は、フツーに考えて反対するようなことではないと思いますが、そのためにいろいろ「禁止事項」ができるということになると、各論レベルでは異論もあるのかなーとも思います。
  • まあ、いっそ、WCAG2.0からは離れ、「一般論として視聴覚困難者等にも配慮するためにはこんなことに気をつけるといいよ」的なフワッとした内容でまとめるというのも手だと思います。そうするとますます「禁止」することの根拠があやふやになり、「推奨」はできても「禁止」は難しいなあと思うのです。
  • 上にも書きましたが、WCAG以外にも、スマホでの閲覧の話とか、HTMLの話とかがまぜこぜになっています。そこらへんも切り分けたり整理したほうが話がスムーズに行くと思います。(別文書にしちゃったほうがいいと思います。)--柒月例祭会話2017年4月14日 (金) 08:35 (UTC)[返信]
返信 (㭍月例祭さん宛) 分かりました。とりあえず、一旦ガイドライン化は棚上げにしたいと思います。節名も変更させていただきました。--新世紀のウィキぺディア会話2017年4月14日 (金) 09:25 (UTC)[返信]
コメント 恐縮です。当座のこととして、「スマホでの閲覧」とか「HTMLの作法」の話も、当面ちょっと棚上げしませんか。特にHTMLの作法の話のかなりの部分は、最終的にはWCAGの話と共通点がありそうなのですが、ひとまずそのことは置いとくことにして。
そして話の進め方。正直これは私も確固たる考えがあるというわけではなくて、他の皆さんの意見も聞きながらです。上では「ランクAを目指すのか決めたほうがいい」的なことを書いちゃいましたけど、実際には「ウィキペディア日本語版はランクAクリアを目指すよ」的な「大きな合意」を形成するのは、きっと難しいだろうと思うのです。上にも書いたように、根本的な仕様にも関わる部分があるし、ランクAのためには「禁止」事項をたくさん設けなければいけないし、いささか非現実的かなと思うのです。
ですが「視聴覚困難者への配慮」を行うこと自体は有益に決まっています。なので、視聴覚困難者への配慮としてこういうことをするといいよ、的な感じでフンワリまとめ、各条項について「ちなみにこの話はWCAGではランクAに位置づけられていますよ」ぐらいの言及とする。つまり、「やるべき」「やらないべき」いずれにせよ「推奨」どまり。
さらに「視聴覚困難者への配慮」は、「読み上げソフトへの配慮」とそれ以外(GIF画像の秒数の件や色のコントラスト比の件など)があり、これらを節わけして説明する。「リンク色を変えない」などのように、視聴覚困難者に限定しない話もあり、それも節わけしたほうがいいようにも思います。(WCAG2.0の3.1以降は、視聴覚困難者とそれ以外、みたいにきれいに分けられないのですが。)
私が見たところ、なんとなく、「読み上げソフトへの配慮」の件は、テキストの書き方を定めたものなので、画像や動画の話よりはとっつきやすく、実現へのハードルも低そうに思います。(ただしこの件が一番、「HTMLの作法」とも通じるところがあります。)なんとなれば、Wikipdia:読み上げソフトへの配慮みたいに、これだけに特化した文書にしてしまうほうが、扱いやすいと思うのです。そうやっていくつかの文書を別々に作り、Wikipedia:アクセシビリティではそれらの各文書を紹介する、という方式のほうがスムーズに行くんじゃないかなあと。今のところは「日本語の読み上げソフトの挙動・仕様」がよくわからないというのは悩みの種なのですが。--柒月例祭会話2017年4月15日 (土) 04:34 (UTC)[返信]
返信 (㭍月例祭さん宛) 了解しました。--新世紀のウィキぺディア会話2017年4月15日 (土) 06:05 (UTC)[返信]
コメント 一応、わたしからも案を出すつもりであることを申し上げておきます。ただし、少し時間がかかるので、その間に議論が進むことを阻むつもりはございません。--ネイ会話2017年4月15日 (土) 06:44 (UTC)[返信]
返信 急がなければいけないようなことではないですし、私としてはネイさんの案をのんびりお待ちするのでいいと思います。その間、私の方でも何かの準備的な作業はするかもしれませんが、話を進めるのは案が出揃ったあとでもいいかなと思います。--柒月例祭会話2017年4月15日 (土) 07:20 (UTC)[返信]
返信 (㭍月例祭さん宛) そうですね。ただ、私は多忙になるため、この先数年はウィキペディアでの編集ができそうになく、来月初めにはウィキペディアから引退する予定です。もし私が引退したら、私はいなかったことにして議論を進めていただいて大丈夫です。--新世紀のウィキぺディア会話2017年4月15日 (土) 07:50 (UTC)[返信]

「動画と音声」節への翻訳加筆[編集]

「動画と音声」節への翻訳加筆を提案します。要点は下記の通り。

  • アニメーションGIF画像:5秒内に収まるようにする。(5秒以上はGIF画像ではなく動画ファイルを使用する)
  • アニメーションGIF画像:1秒内に3回以上のを超える閃光が出ないようにする。(発作を引き起こす恐れがあるため)
  • 動画/音声:キャプション/字幕をつける(コモンズに詳しい説明あり)。
  • 動画:耳の不自由な方にはクローズドキャプションを使う必要がありますが、これは現時点では機能が整っておらずPhabricatorで要望が出されたままです。そのため、クローズドキャプションは現時点ではウィキペディア外でしか利用できません。

本文書は現時点では草案にすぎず、内容が広く議論され受け入れられているとは言えませんので、2、3日間反対がなければ英語版からの翻訳で当該節を加筆します。--ネイ会話2018年12月26日 (水) 15:15 (UTC)[返信]

コメント 大筋賛成、各論反対ってやつなんですが、「翻訳」での加筆は賛成しません。なぜならば、それだと「英語版」が根拠になってしまうからです。別に翻訳など不必要で、WCAG2.0文書のガイドラインを根拠とすることで、上の内容はカバーできます。また、「GIF」に限定するのはよしましょう。GIFは典型例ではあるけれど、それ以外はオッケーって話ではないのですから。枝葉よりも、原理原則を理解し示す必要があります。

  • 2.2.2 5秒よりも長い動画的情報は、動きを制御する機能が必要(→GIFはダメ、動画はOK)
  • WCAG文書では「自動的に開始」の場合には動きを制御する機能が必要とされているので、とにかくGIFはダメともいえる。ただしGIFはにせよ動画にせよ、個人設定やブラウザ設定で制御できるので、まあ。
  • 「GIFダメ、動画がいい」とかそういう話ではなくて、「動作を制御する機構が備わっていること」が求められています。英語版もちゃんとそう書いています。その機能が(何かしらの技術で)確保されているならば、GIFで300秒だっていいんですよ。
  • 2.3.1 1秒に3回を超える閃光はダメ。 - ご提案内容は「3回以上」なので、違いがあります。
  • WCAG文書では「閃光の程度」に関する定義がありますが、まあそれはおいときましょう。
  • 1.2 映像には音声を(目が見えない人用)、音声・動画には字幕を。

これらはいずれも「レベルA」(最低限クリアしなければいけない)ものなので、優先順位は高いです。ほかにもレベルAはありますが、まあ、一度には大変なので。

これらを「アクセシビリティに配慮するためにはこういうことに気をつける必要がありますよ」と紹介することは、啓蒙活動としてなんにもデメリットはないです。が、一般の執筆者にとっては、難しい話ばかりですね。ほとんど、GIFや動画を自作する人にしか活用できない条項でしょうねえ。これを根拠に「このGIFは違反だから除去します」みたいなことを始める人が出るとはなかなか想定しにくいし、「このGIFは違反なのでOKなものに改良します」みたいな人はもっと想定しにくい。

あと、「草案に過ぎないから云々」はそのとおりなのですが、だからといって「2、3日で」っていうのはやめましょうよ。普通にWikipedia:合意形成どおり、7日間でいいじゃないですか。急ぐ必要はないですし、あとになって合意形成に瑕疵があると非難されかねないようなことをする必要はないです。

なんか無理に苦言をいいますが、「3以上」と「3超」はだいぶ違いますよね。原文は「more than three」ですけど。こんなのはうっかりミス程度のものでしょうけれど、いちど明文化したら独り歩きしちゃったりするんですよ。そこらへんをそれなりにチェックする意味でも、「2、3日」は短すぎます。

明らかに改善なのですから、堂々とやりましょう。--柒月例祭会話2018年12月26日 (水) 16:08 (UTC)[返信]

  • 「翻訳加筆」とはいっても、英語版ではWCAGへのリンクを脚注に置いているので、実質的に根拠となるのはWCAGであり、私にとって翻訳加筆のほうがやりやすいだけです。
  • せっかくですから、当該節だけではなくほかの部分でもそのような脚注をつけるのはどうでしょう。もっとも、その場合は2、3日はさすがに足りないとは思いますが、年末までになんとかできれば。また、それを行う場合は一度に更新したいので、編集は一旦保留ということで。
  • 「3回以上」を「3回を超える」に修正しました。
  • GIF以外のアニメーション画像(例えばAPNG)は使えるものの不具合があったりします(サムネイルが動かない場合があります)。将来使われるのに備えてGIFに限定しないことに賛成します(修正しました)。
  • 5秒以上のアニメーション画像が表示される可能性に備えて、予めブラウザなどが設定されていることを想定しないほうがいいではないかと考えます。MediaWikiで動作制御機能が実装されたら5秒の規定は不要になりますが、それがない現状では仕方がありません。
  • 「閃光の程度」まで書くとなると、複雑すぎますので、ガイドライン草案ではなく「ウィキペディア向け動画の作成の手引き書」を作成することになるかと思います。
  • 現段階で一気に解決できないと思いますが、Special:LintErrorsによると全名前空間で終了タグの不足が30万件以上あるので、4.1.1(レベルA)をクリアするまでの道のりがとてつもなく遠そうです。--ネイ会話2018年12月27日 (木) 02:03 (UTC)[返信]
返信 了解しました。基本的な方向性は賛成ですから、まずはネイさんの投稿をお待ちして、それで何かあれば意見します。(これでいい、というときもその旨を申し上げます)--柒月例祭会話2018年12月27日 (木) 04:13 (UTC)[返信]
返信 Wikipedia‐ノート:アクセシビリティ/2019年1月1日改訂案として作成しました(差分)。色々と編集しているうちに結構大きな変更になりましたので、「これでいい」可能性はかなり低くなったと思いますが、コメントをいただければ幸いです。--ネイ会話2019年1月1日 (火) 06:02 (UTC)[返信]
認知しました(遅くなりすみません)。改めてコメントしますので少しお時間をください。--柒月例祭会話2019年1月4日 (金) 16:55 (UTC)[返信]
返信 拝見しました。結論を先に言えば、ひとまず、ご提案内容で大きな異論はありません。微細な修正・今後の課題はあります。修正は下記3点です。
  • 「導入部」の最初の「、」の消し忘れ
  • 「画像」の「画像にはキャプションも付けましょう」は「付けるべきです」等の表現に。(他の部分では「○○です」「べきです」「推奨されます」「必要があります」などの表現にほぼ統一されています。)
  • 「動画と音声」の「つけるようにしてください」も同様です。
後者2点の文末表現については、強制力(?)の強さの度合いに応じて表現を揃える、ということを検討してもいいのかもしれません。難しいですけどね。「必ずしなければなりません」「するべきです/推奨されます」「検討してください/注意してください」みたいな。たぶん、WCAG2.0の「レベルA」とかに対応するのでしょうけれど。まあ現時点ではガイドラインに満たないのでそこまで拘る必要もないかもしれないですし、特に画像、動画、音声については「キャプションをつけろ」と言われても実務的には容易ではないでしょうから、「べき/推奨」どまりなんでしょうねえ。
今後の課題については節を改めます。--柒月例祭会話2019年1月5日 (土) 05:23 (UTC)[返信]
(インデント戻す)1と「障害」は修正しました。2は代替テキストが推奨、キャプションが「つけるべき」としています。3は推奨としました。キャプションをつける難しさについては動画と音声と比べると画像のほうがずっと簡単なので、画像のみ「つけるべき」としました。--ネイ会話2019年1月5日 (土) 06:12 (UTC)[返信]
返信 ありがとうございます。これでネイさんのご提案に賛成します。--柒月例祭会話2019年1月5日 (土) 06:45 (UTC)[返信]
報告 特に反対がなかったため編集しました。--ネイ会話2019年1月19日 (土) 08:58 (UTC)[返信]

冒頭部の変更提案[編集]

いまの冒頭部はやや長いと感じます。また、文書全体として各論に入る前に、基本的な考え方を示し、頻出するWCAG 2.0の紹介もするべきと思います。

修正案をWikipedia‐ノート:アクセシビリティ/2019年1月5日改訂案に示しました。いかがでしょう?--柒月例祭会話2019年1月5日 (土) 06:44 (UTC)[返信]

少し検討させてください。Wikipedia:多様な閲覧環境に配慮するも工事中とのことなので、併せて読みたいと思います。(ざっと見て気付けるのは1点。「スマートホン」より「スマートフォン」表記のほうが一般的ではありませんでしょうか。)--ネイ会話2019年1月6日 (日) 17:24 (UTC)[返信]
「ホン」を「フォン」修正しました。(スマホというので意識せず「ホン」としていました。NHK放送文化研究所「スマートホン」か「スマートフォン」かというのもありました)--柒月例祭会話2019年1月18日 (金) 06:54 (UTC)[返信]
ありがとうございます。変更に 賛成 します。(「Wikipedia:多様な閲覧環境に配慮するも参照」は{{See also}}を使ったほうがいいと思いますが、細かいことですし採用するかはお任せ致します。)--ネイ会話2019年1月18日 (金) 07:47 (UTC)[返信]
特に反対がない場合、25日をもって合意成立とすることを予告しておきます。--ネイ会話2019年1月19日 (土) 08:59 (UTC)[返信]
コメント 合意が成立したとみなします。改訂案のページからの履歴継承を回避できるということで、㭍月例祭さんが転記していただければと思います。--ネイ会話2019年2月1日 (金) 17:25 (UTC)[返信]
報告 ありがとうございます。修正をしました。--柒月例祭会話2019年2月2日 (土) 02:45 (UTC)[返信]

「文章」節の検討課題[編集]

腑に落ちないところがいくつかあります。ここはもっぱらスクリーンリーダーの挙動を考えて書かれているようですが、2009年以降、あまり整備されていないようで、近年の状況を正しく反映していないようにも思います。

(2)「文章」の2の打消し線の説明
  • 「記事中の」議論のある記述を打ち消し線で修正するな、とあります。「記事」(=標準名前空間)に限定するならば、これはわかります。
  • しかし続いて「ウィキペディアの方針や削除の議論に・・・」とあります。これは、標準名前空間以外やノート・議論ページでも打ち消し線での修正をするな、と読めます。
  • スクリーンリーダーの挙動のことだけを考えると、議論ページでも打消し線を使うなということなのでしょう。ですが、そこにも「そうした議論においてよく用いられ」とあるように、現状の実態・慣習とはかけ離れた要求のように思います。さて・・・?。
  • この部分は、ショートカットの名称が「WP:NOSTRIKE」であるところから推定できるのですが、旧い削除タグ「<strike></strike>」・「<s></s>」(訂正)がダメ、ということではないかと思います。どちらもHTML4(1997年)の時点で非推奨、HTML5(2014年)で廃止されています。HTML5では「削除された要素」を意味する打ち消し線(<del></del>)が採用されています。「<ins></ins>」も同様です。WP:REDACTHelp:ページの編集#取り消し線・下線でもdelとinsの使用を推奨しています。
  • ちょっとアレな情報源なのですが、[2](2018年9月)あたりの眺めると、HTML5準拠のdel・insはスクリーンリーダーが対応しつつあるようです?
(3)カタカナ表記か翻字化せよ?
  • 対象となるものは限定的でしょうけれど、普通は「カタカナ表記や翻字」が困難だからこそ「日本語やアルファベット」以外が用いられているはずです。固有名詞や専門用語など、ヘタにカタカナ化しないほうがいい場合もあるでしょう。ここでは「カタカナ化せよ」というよりも、「代替テキストを整備せよ」としたほうがいいのでは。--柒月例祭会話2019年1月5日 (土) 07:19 (UTC)[返信]
  • コメント (2)については英語版だと「記事では使わない」「議論では打ち消し線がよく使われます。スクリーンリーダーを使う編集者は議論に参加するとき、要素の意味を読み取るよう(insやdelといった意味を無視して普通の文章と同様に読み上げないよう)スクリーンリーダーを設定してください」となっています。日本語版も記事限定に変更するのはどうでしょう。(3)については、代替テキスト=翻字(ラテン文字表記を併記)ではないでしょうか。特に翻字は英語圏でも必要となるため翻字用のツールがあり、そこまで難しくないと思います。--ネイ会話2019年1月6日 (日) 17:21 (UTC)[返信]
返信 ありがとうございます。(2)については、「動画と音声」の件が落ち着いたときにでも改定しましょう。
(3)についてはナルホド。正直言うと、ここらへんはUnicode#日本語環境でのUnicodeの諸問題あたりを眺めても、私の知識と能力では手に余るところがあります。具体的にいくつかの実例を挙げたり、{{ラテン翻字}}などのテンプレートを列記するようにするとわかりやすくなるようには思います。
このほかいまはハートマーク、ダガーマークに言及がありますが、経験的には「〜(波ダッシュ)」とか、ダッシュ記号ハイフン記号プラス記号とマイナス記号#マイナス記号あたりをめぐって、ときおりトラブル事例を見かけるように思います。ふつうには見かけ上どっちでもいいような感じはするけれど、機械に読み取らせる場合には注意が必要になる例、として少し説明を増やしてもいいようにも感じました。--柒月例祭会話2019年1月18日 (金) 07:21 (UTC)[返信]

すみません、「動画と音声」の件が終了した後も本件を取り上げませんでした。正式に提案します。

  • (2)に関しては、記事ではdelもstrikeも使うべきではないということで、草案の文章を下記にします。

打ち消し線これは例です。)を使って、記事中の記述を修正しないでください。"<!--"と"-->"によるコメントアウトを使うか、完全に除去してしまってください。普通、スクリーンリーダーは文章の強調(イタリックや太字、下線など)を無視します。そのため打消し線の引かれた文章も、他の文と同じく読み上げられてしまいます。なお、ウィキペディアにおける議論では打ち消し線のある文章がよく用いられていますが、その場合は「打ち消し線」という意味の<strike></strike>タグを使わずに、「削除された要素」を意味する<del></del>タグを利用してください。スクリーンリーダーを使う編集者は議論に参加するとき、要素の意味を読み取るよう(insやdelといった意味を無視して普通の文章と同様に読み上げないよう)スクリーンリーダーを設定してください。

  • (3)に関しては、{{ラテン翻字}}に例がありますので、そちらへのリンクだけ追加することとします。

日本語ラテン文字に無い文字は、カタカナ表記するか翻字してください({{ラテン翻字}}を参照)。Unicodeをサポートしていないスクリーンリーダーは、これらの文字を読みあげられないことがあります。(英語圏における記述:Unicodeに対応していないスクリーンリーダーでは、ISO/IEC 8859-1(Laten-1)以外の文字はクエスチョンマークとして読み上げるでしょう。最も普及したスクリーンリーダーのJAWSの最新版でも、Unicode文字を読むのは非常に難しいです。)また、♥(ハートマーク)のような読めない文字を使わず、その代わりに代替テキストつきの画像を使用してください。このようなシンボルの一部には{{Dagger}}のように代替テキストつきの画像を表示させるテンプレートが存在する。Category:画像挿入テンプレートを参照してください。

  • 見た目が似ている約物は別立てにします。

見た目がよく似ている約物は区別してください。表示ではほとんど変わらなくても、スクリーンリーダーでは全く違う文字として読み上げられます。例としては波ダッシュ(〜)と全角チルダ(~)、ダッシュ(—)とマイナス(−)とハイフン(-)などがあります。

返信 ありがとうございます。大筋で反対はないのですが、私なりに別案を考えてみました。これです。

  • 大雑把に言うと、中身は一緒です。「約物」と「翻字」はネイさんの案をベースにしています。
  • 節・小節だてにしました。順序を少し入れ替えています。(順序はなんとなーく近そうな話を並べただけで、たいした重要ではないです)
  • 「こうせよ(するな)」と「なぜならば(解説)」を少し分けました。なんとなく背景色をつけちゃいましたが、色は不要でもいいです。(アクセシビリティ文書で背景色をつけるというのはちょっとアレかもしれないですし)
  • 打ち消し線については少し細かく書きました。記事「など」というのは、カテゴリとかテンプレートとか、標準名前空間に準じるような範囲をさしている(つもり)です。ここはもうちょっとカチっと定義できるといいかも。
  • 全体としては、従前やネイさん案よりも肥大化してしまっています。--柒月例祭会話2019年4月14日 (日) 14:01 (UTC)[返信]
    • 返信 後ほど柒月例祭さんの別案についてコメントしますが、一点だけ。わたしの案でも柒月例祭さんの案でも残っている「英語圏における記述」についてです。そもそも日本語の文字はISO/IEC 8859-1外であり、今では日本語を読み上げるスクリーンリーダーもありますので、日本語版の文書で当該記述を残す必要はないのではないでしょうか。また、残す場合でも"Laten"を"Latin"に修正すべきでしょう。--ネイ会話2019年4月14日 (日) 14:52 (UTC)[返信]
      • ごもっとも。(英語圏・・・)はまるっと不要ですね。
      • (以前もどこかで書いたのですが)正直言って、「障害者向けの」「スクリーンリーダー」と書いてしまっているのですが、実際問題今どきのスクリーンリーダーの一般的な挙動がどうなのか、ちゃんと調べておらず、あまりよくわかっていないんですよね。従前からある記述をそのままにしているだけで。
      • 「信頼できる情報源」かどうかはおいといて、スクリーンリーダーについて色々ググるといろいろでてきます。(例2。)本格的なソフトは何万円とか10万円以上とかで、「最も普及しているもの」で15万円だそうで、さすがに購入して検証するのもアレですし、じゃあ無料フリーソフトで試したとして、フリーソフトに合わせるのかというのもあります。
      • また、スマホのアプリとか、もはや「視覚障害者向け」とばかり言えないところもあり、単に「スクリーンリーダー(読み上げソフト)」でいいのかもしれません。--柒月例祭会話2019年4月15日 (月) 08:32 (UTC)[返信]

記事名におけるダッシュの扱いについて[編集]

本来ならばWP:NCで議論すべきことですが、まずこちらで確認してから議論を提起したいと思います。すなわち、先日の改訂で追加されたハイフンとダッシュに関する注意書きですが、これは墺土戦争 (1787年-1791年)(ハイフン使用)のようなケースにも適用されるのでしょうか。適用すべきとした場合は墺土戦争 (1787年–1791年)(enダッシュ使用)が正しい記事名になりますので、その場合はWP:NCで改訂を提起します。--ネイ会話2019年4月29日 (月) 09:25 (UTC)[返信]

(補足)WP:HYPHENもありますが、ダッシュを全く使わないというのはアクセシビリティ的にはどうなのか、という問題もあります。--ネイ会話2019年4月29日 (月) 09:58 (UTC)[返信]
コメント うーん、これは確かにWP:HYPHENWikipedia:アクセシビリティ#約物や符号に関する注意点はちょっと合わないですね。
このWP:HYPHENあたりは、2004年の初案からあったもので、いま「アクセシビリティ」を念頭にいれて見直すと、どういう理屈でこのルールが有るのか根拠が不明です。
理屈から言えば、後発のWikipedia:アクセシビリティのほうが「正しく」いまのwebのマナーに適っているハズです・・・が、WP:HYPHENの規定がながくルール化されていることを思うと悩みますね。WP:HYPHENの「ハイフンマイナスを使え」というのは代用文字ですから「ダメじゃない」のでしょうけど、Wikipedia:アクセシビリティのように正確に使い分けるほうがベターですよね。でもいまさら・・・という感じもしますね。
広い告知と意見を募りたいところですが、「アクセシビリティ」のなかみが「ベター」ではあるから今後は気をつけるのが望ましい、でも既にあるものを片端から直さなくてもいい(直すなとは言っていない)、ってあたりが落とし所でしょうかねえ?
墺土戦争の件は、理論上はenダッシュが正しく、修正すべきでしょうけれど、今すぐ修正しなければいけない差し迫った問題というわけでもないでしょうから、WP:HYPHENの話をいったんまとめてからのほうがいいのかもしれないですね。--柒月例祭会話2019年4月29日 (月) 10:25 (UTC)[返信]
  • (コメント)人名でもハイフンマイナス使った記事名がぽつぽつある(例: アレグザンダー・フッド (初代ブリッドポート子爵 1726-1814))ので、変更するならボットでまとめてやってしまったほうが後々面倒なことにならないような気もします。ところでenダッシュを使用すべきとなった場合、同様にダブルハイフンの代用(代用であることがWP:NCに明記されています)としている全角等号もダブルハイフンに置換すべきということになるのでしょうか。私の環境だとenダッシュやダブルハイフンは入力する方法がわからないのですが、アクセシビリティ的にはまずそうですよね。「イコール」とか読み上げられてたら…。―霧木諒二会話2019年4月30日 (火) 04:41 (UTC)[返信]
  • たしかに、特に検索する場合においては「入力の困難さ」がネックになります。そのため、記事名はそのまま(enダッシュもダブルハイフンも使わない、またはリダイレクト作成を許可するに留まる)、内容では正しく使用することを推奨(強制はしない)、というのが関の山ではないでしょうか。ボットによる修正は草取り編集者の負担を減らすという意味で賛成します。--ネイ会話2019年5月2日 (木) 09:40 (UTC)[返信]

「打ち消し線」の説明について[編集]

「打ち消し線」について調べてみたのですが、現行の勧告HTML 5.2でも、ドラフトのHTML 5.3でも<s>,<del>,<ins>の3つとも(非推奨でも廃止でもなく)残存しているようです。

HTML 5.2 - W3C Recommendation, 14 December 2017

HTML HyperText Markup Language MDN

HTML 5.3 - W3C Working Draft, 18 October 2018

そうすると、「打ち消し線」の説明中にある<s>は廃止済みだから使用不可、<del>と<ins>は使用可という説明は規格と整合性が取れていないことになってしまいます。 詳しく調べたわけではないのですが、<s>と<del>を使い分けせよ、という規格書の指示を鑑みれば、議論が紛糾して、HTML 5.xの議論の中で復活したエレメントなのかもしれません。

標準名前空間にある見出し語「打ち消し線」にある用例ソース「{{strike|打ち消される文字}}」は「<span style="display: inline;"><del>打ち消される文字</del></span>」に展開されるようですので、廃止された<strike>は実質的に存在しないのでしょうが、<s>が「いかなる場合も禁止」となる根拠がなくなってしまうようです。 アクセシビリティ上の注意喚起は<s>でも<del>でも同様です。 元から標準名前空間では<s><del><ins>いずれも全面不可ということのようですので、影響はあまりないだろうとは思いますが、規格上は使用できるけれども、歴史的な経緯から<s>はやめましょう、とでも「(解説)」の一部も文章を改定する余地があるかもしれません。 小説家の原稿用紙の文字起こしをするときなどは、標準名前空間でも<s><del>などが使えると便利でしょうけれども、その場合は「{{strike|打ち消される文字}}」を使えば良いのでしょうね。 --灰は灰に会話2019年7月2日 (火) 09:19 (UTC)[返信]

外国語セクション[編集]

文章セクションにおいて外国語のセクションが2つあることかわ気になりました。なにか理由などあるのでしょうか。--そらたこ🐙(会話) 2019年8月24日 (土) 17:15 (UTC)[返信]

WikitableやInfobox内での箇条書きについて[編集]

提案 アクセシビリティの観点から、WikitableInfobox内で中黒のない箇条書きを表現するためには、<br>による擬似的な箇条書きではなく、{{Plainlist}}や{{Unbulleted list}}を使用するべきだと思うので、Wikipedia:アクセシビリティ#表にこのことを加筆してはどうでしょうか。--Momiji-Penguin会話2019年12月19日 (木) 17:24 (UTC)[返信]

  • 賛成 「箇条書き」節のほうにすべきかとも思いますが、いずれにしてもアクセシビリティ上はこれらのテンプレートを使用すべきであると考えます。--ネイ会話2020年3月28日 (土) 03:43 (UTC)[返信]

記事中のiタグbタグの扱いについて[編集]

Baudanbau20さんは、直近では88800680において、iタグをウィキテキストに変えられました。その前にコメントアウトで「変えないでください」と書いていたのにも拘わらずです。これを実施されたBaudanbau20さんに、私は2021年の9月26日利用者‐会話:Baudanbau20#編集に関する質問にてお尋ねしておりますが、氏は返事を返さないまま編集をおこなっているようです。
はっきり申しますと、私は''hoge''がかなり嫌いです。編集画面で見ると微妙に斜め・太字になって美しくありません(ここをご覧ください)。
いつも推奨方式を用いられている方は、いったいどのような時にi, bタグを用いるのかと疑問と思います。そもそも、平文中には基本的に用いません。用いるのは、
  1. テンプレート中 - こちらのほうがより美しいからです。
  2. 外部エディタで文章を書くとき - Wikipedia上ならば、Ctrl+B, Ctrl+Iで瞬時に変えられますが、メモ帳ではそうはいきません。Shiftを押しながら"7"キーを、指が無理な体制で6回押すよりは、<b></b>と書くほうが私は好きです。
私が、「推薦方式は嫌だ。美しいほうがよい」というのにも根拠はありませんが、本草案も「一般的に...とされている」とあり、同様に根拠はありません。何度も言うように、読み上げの問題なら他のTemplateも使うなと言っているのでしょうか。それは暴論です。なお、私は面倒なのでlangテンプレートも使うつもりはありません。どなたか、賛同くださるかまたは私が納得できる理由をお願い致します。ご意見がないならば削除し、ファラオの装身具およびツタンカーメンなどの翻字部分をiに戻そうと思います。--Sethemhat会話2022年4月16日 (土) 15:18 (UTC)[返信]
  • 反対 結論から言うと「推奨」にはHTML5という根拠があります
  • いちおう、「MediaWikiの作法の話」と「一般的なHTML作法の話」は区別する必要はあります。とはいえ、ほとんどは共通しています。このiタグbタグについては、この両者が関わります。
  • 端的にいうと、<i>タグはもともと、「イタリック(斜体)で表示しろ、理由は知らん」という指示です。<b>タグは「太字で表示しろ、理由は知らん」という指示です。
  • こうした指示は古いタイプのHTMLの作法です。今のHTMLの作法では、例えば「重要なので強調表示しろ、方法は任せる」という指示の方が適切とされています。たとえば「strongタグ」や「emタグ」がそれにあたります。HTML5のルールでは、古いタイプであるbとかiは「非推奨」にまではなっていないものの、目的に応じてdfnタグ、strongタグ、emタグなどを用いるべきとされています。
  • で、今は<i>タグは「他のテキストと区別するようにしろ、方法は任せる」という意味合いに変更されていて、基本的にはイタリックを表示します。<i>タグには「重要だから」字体を変えろという目的は持っていなくて、別に「重要だから」ではないけども、引用とか固有名詞とか慣用句だとかをテキスト全体の中で区別できるように、という目的を持っています。「de facto」とか。
  • 一方、MediaWikiは独自のマークアップ文法を持っています。で、今のところ、「''de facto''」というマークアップは、「他との区別をしろ」という意味を持っていて、「<i>de facto</i>」と表示させるようになっていますから、結局一緒です。なので、今のところは、どちらかにこだわってもほとんど意味はありません。ただ、将来的にもしもMediaWikiの仕様が変更になったときには、「''de facto''」という文法が別の表示を返すようになるかもしれません。MediaWikiの作法である「''de facto''」としておけば、そのときに自動的に追随しますが、「<i>de facto</i>」としてしまうと追随してくれない、ということになります。とはいえまあ、今の時点での現実的なリスクの大小の話をすれば、「ほとんど関係ない」ということになるとは思いますけども。
  • 美しいとか美しくないという審美的な価値観については、主観に基づくもので、好みの問題です。特にイタリックの「美しさ」については、フォントの基本設定が昔と変わった(イタリック体を持っているフォントと、無理やり斜めに傾けてるフォントがあるとか)等の事情もあるようです。で、現実問題としては、ブラウザやPCの設定、個人設定でどうにでもなるものです。入力の手間についても同様です。好みの話でいうと、私は<i>○</i>と入力するより''○''と入力するほうがはるかにラクですね。
  • また、私はごく一般的なWindows環境・初期設定のままでアクセスしていますので、いまは日本語文章に「<i>」タグや「'' ''」を設定しても、見かけ上は斜体にならず何も変わりません。しかしそれはあくまで見かけ上の問題であって、パソコン・ブラウザさんは「意味の違い」をソースから受け取っています。
  • 難しく突っ込んで考えていくと、MediaWikiの仕様全体がHTML5の作法にがっつり準拠しているわけではないので、過度にこだわりすぎるのもどうか、とは思います。あくまでも空想上の理論上の可能性にすぎませんが、MediaWikiの仕様と、HTML5やその次世代仕様と、それぞれ大きく異る方向に進化した場合には、HTMLの作法にこだわるのは間違いになる、ということにはなります。が、そういう可能性はほとんど無いか、少なくとも我々が今心配することではないでしょう。--柒月例祭会話2022年4月16日 (土) 16:46 (UTC)[返信]
  • 返信 迅速なお返事ありがとうございます。しかしながら、柒月例祭さんの論は直接的な回答にはなっていないのではないでしょうか。貴殿の論は、「HTML5でi, bはあまり推奨されていない方式であるため、Jawp上でも用いないべきだ」となっていると思います。私が考えるのは、HTML5とアクセシビリティの話は関係ない話で、もし仮にHTMLの観点よりiタグの使用をしないべきと考えても、それはHTMLの解説文書に書くべき内容であり、アクセシビリティの草案に書くべき内容ではないと思います。
さらに、私はHTMLの専門であるプログラマーではなく、ウィキペディアンです。よって、HTMLの勧告に従う義務はまったくありませんし、自身が使用したいと思った表記を用いる自由を持っていると思います。英語版のアクセシビリティの文書でも、
一般に、表やその他のブロックレベルの要素のスタイルは、インライン属性ではなく、CSSクラスを使用して設定する必要がある
一般に、記事では、使用可能なHTML要素の限られた方式よりもwikiマークアップを使用する必要がある。特に、HTMLスタイル要素を使用したりテキストをフォーマットしたりはするな。
とあたかもこの論が一般論のように述べており、明確な根拠はありません(強調は引用者。今はJawp上入力なのでCtrl+Bで太字化しました)。繰り返しますが、私は「Jawp上ではiタグを使用することがスタンダードだ」と申しているのではなく、「別にiでもbでもユーザーが使いたかったら使えばよいじゃないか」と言いたいのです。Baudanbau20さんの、このアクセシビリティ文書を根拠としたiタグからウィキ文法への修正は、英語版に書いてあるように「表面上は変わりない」のであり、はっきり申しまして無駄な作業です(作業が無駄と言っているのであって、その作業を行っている人物を中傷する意図はありません)。もっと有効な時間の使い方もあると思います。
このような形の「編集の自由」は認められないのでしょうか?--Sethemhat会話2022年4月17日 (日) 15:04 (UTC)[返信]
コメント 根拠とおっしゃいますが、基本的に、共同作業の場であるWikipediaで活動する上で、守らなければならないのは「コミュニティの合意」です。それが「根拠」なのです。これは別にWikipediaに限ったことではなく、現実・ネットのいずれにしても多くの社会/コミュニティで共通でしょう。イヤならばそのコミュニティを去ることができます。残るならば従うべきルールはあるのでは。
「HTML5云々」は、理屈の上では、コミュニティの各構成員が考えたり意見を定めたりする「もと」になるものでしょう。コミュニティ参加者の多くが「HTML5はだいじだから、準拠すべきだね」と考えればそういう合意に至るでしょうし、逆に多数が「HTML5なんて知ったことか」と考えればそうなるかもしれません。ただしここでいう「コミュニティ」はJawpだけでなく、世界中のWikipediaが該当するでしょう。もしも仮にJawpだけが世界のWikipediaのスタンダードに反する方向に舵を切ろうとしても、より多数派であるWikipedia全体によって否定されるのかもしれません。(あと、財団ってのもありますけど。)
Jawpは「無法地帯」ではありません。各利用者が「オレの好み」だけで編集してはめちゃくちゃになるでしょう。私は技術系ではないので、正直、HTMLの作法とか専門的な話になるとお手上げです。そのうえで言いますけど、Wikipediaの「データ」(html記述を含む)は、さまざまな方法で利用されます。必ずしもパソコンのブラウザで閲覧するとは限りません。たとえば(もはや昔の遺物になりましたが)「ガラケー」で見ることもあったでしょう。将来的にまた別の閲覧手段が登場するかもしれません。そういうときに、なるだけ適切な(=世界標準の)HTMLの作法に基づいたデータであったほうが、閲覧者がスムーズに見ることができるでしょう。もしかすると、「Sethemhatさんが自分好みにした箇所だけちゃんと閲覧できないぞ」ということになるのかもしれないのです。一方、Wikipediaの標準的な作法に則っているのにちゃんと閲覧出来ない場合には、それは技術者の責任でしょう。
・・・といろいろ書きましたけど、実際問題としては現状では「''Wikipedia''」と「<i>Wikipedia</i>」は「Wikipedia」と「Wikipedia」と表示され、すなわちごく一般的な環境では見かけ上一緒になりますので、過度に気にしすぎることはありません。なので貴方がWikipediaに情報を提供するうえで、書式にそこまで気にする必要はないでしょう。「HTML5」は、Wikipediaが出来たのより後発のものです(より正確には、5.1とか5.2とか進化しています。5.2は2017年ものだそうです。)。そのせいか、Wikipediaの基本仕様が最新のHTML5に準拠していない部分もありますし、われわれいちユーザーが過度に気にしすぎる必要もないとは思います。世の中には「HTML5.2」どころか、HTML4とか3とかの時代のサイトがごろごろあります。まあ、世の中のブラウザも日々更新されているので、もしかすると、古いスタイルで記述されたサイトが閲覧できなくなる、ということがいつかやってくるのかもしれません(当座は非現実的な仮定なんだろうとも思いますけど)。適切なスタイルに更新することは、それを防ぐことにななるのでしょう。
ただ、それを「HTML的に正しい方式」に改めるのを妨げるような行為には、それこそ根拠がないということにもなります。究極的には、Sethemhatさんが「Sethemhatさん好み」としか根拠がないような事柄であまりにも問題を起こす人だ、とコミュニティに判断された場合には、「問題利用者だ」とみなされることになるわけです。
Wikipediaは共同作業の場なので、過度に「自分好み」を追求するのはできないです。どうしてもというなら自分でHPを立ち上げるということになるでしょう。あきらめたり妥協したりすることも必要ですよ。--柒月例祭会話2022年4月17日 (日) 17:48 (UTC)[返信]
返信 (柒月例祭さん宛) 「守らなければならないのは『コミュニティの合意』です。」と仰いますが、記事内容に関わったり、運営にかかわる方針であれば大多数の意見に勿論従いましょう。しかし、この件に関しては個人の編集嗜好の問題であり、別にそれでエラーが発生しない限りそれでいいと思います。Jawpの編集者は、jawpにより良質な記事/編集を提供するなどして、jawpを発展させることが本業でしょうし、少なくとも私はそう思って編集に励んでおります。もしこの件で大多数の合意に従わないという理由で私がjawpを去った場合、jawpはエジプト関係記事が加筆/改善されないという点でiタグbタグが残置されるよりも大きな損失を被る、と断言は(失礼ながら)できます。この件は正直些事にしか思えず、議論は不毛と思います(お前が折れろって話になりますが)。
...とはいえ、「Sethemhatさんが自分好みにした箇所だけちゃんと閲覧できない」という事態は困りますね。そのような事にはなってほしくはないのですが、しかしどうも頑固になってしまって折れられる気がしません。
ここで、「『HTML的に正しい方式』に改めるのを妨げるような行為には、それこそ根拠がない」とは全くその通りでしたので、Baudanbau20さんの訂正編集を私は止めるつもりはありません。しかし、私がウィキマークアップに従うわけでもありません。これは「過度」ではない個人の自由の範囲に入るだろうからです。上にも書きましたが、これがなんとかの方針に抵触するから、と言われて、その内容が納得できるものであれば喜んで変えますが、柒月例祭さんのご説明を伺っても、「私の好きなようにしたい」という感想しか出てこないのが(他の方には申し訳ないですが、残念ながら)私の脳内の現状です。すでに最近、多くの方の反対意見を頂き提案を一つ取り下げました。これ以上私が折れるのは精神的に無理とも言えます。--Sethemhat会話2022年5月4日 (水) 12:24 (UTC)[返信]
このノートの目的としている話からは少々外れてしまうのですけれど、この節の名称には「記事中のiタグbタグの扱いについて」とありますので、ソースの見易さや、ミスの防止の観点で、少しだけ書かせていただきます。
Wikipediaの場合、<i>を使わないとミスが誘発され易いのは、記事名が生物の学名である時の冒頭の強調の場所のように、限られた場所だけではないかと、私は考えます。要するに、5回もapostropheを単語の前後に正確に並べねばならず、それでいて、学名をイタリック体にしそこなった場合には、学名をイタリックで書くという当然の事すら知らん者がWikipediaの編纂に関わっていると思われかねず、つまらない事で百科事典としての品位を失墜させかねないという問題に尽きると思うのです。実際に、アップの直前のチェックで気付けたから事無きを得たものの、正確に5回のapostropheが打ち込まれておらずに修正した経験が、私には有ります。
なお、現状のWikipediaにおいて、<b>は不要だと思います。apostropheを3つまでなら、あまりミスも出ないと思いますし、これまでの所、私は不便を感じていません。それに<b>を使うよりも、1 byteだけですけれど、ソースが節約できますから、体感はできないでしょうけれど、理屈の上では、ソースにアクセスしたい時にも負荷が少ないはずです。ですから、<b>をapostropheを3つに置換してくれている事は、雑草取りとして歓迎します。
それを言えば、<i>ならapostropheを2つなので、3 bytesも節約できるわけで、ですから、単独で<i>を使っている場所ならば、どんどん置換した方が良いでしょう。2回のapostropheなら、普通はミスしませんから。
ですので、記事冒頭の1回だけの場所、タグで書けば「<b><i>(学名)</b></i>」の場所、5回もapostropheを正確に連続で打ち込む事を求められる場所だけは、ミスの防止の観点から、それも百科事典としての品位を保つために重要なのは、学名などのようにイタリック体で書くべき文字に対して、きちんと「イタリック体で表示しろ」と指示できる<i>を使った方が良いと、私は思います。
また、このミス防止の観点から、必ずイタリック体で表示すべき文字については、敢えて、<i>を使うという形にするという議論が有れば、私は反対しません。逆に、<b>の使用については、明確に反対します。--G-Sounds会話2023年11月20日 (月) 23:20 (UTC)[返信]
ミス防止の観点ならば、ビジュアルモードでは当然不要だとして、ソースモードでも構文の強調で十分(apostropheの数が間違っているときはソースの表示が崩れるので、プレビューしなくても容易に発見できる)かと思います。--ネイ会話2023年11月21日 (火) 01:36 (UTC)[返信]
  • 堂々巡りになってしまうと思いますが、「ミス防止」であれば、結局「lt;をt;と入力してしまった」みたいなミスも起こりうるのでは・・・
  • (きっと賛同は集まらないと思いますが)「生物学上の学名の表記」のように場面が限定されるのであれば、個々の記事で「'」や「<i>タグ」などを毎回入力するのではなく、テンプレート化するという方法が考えられます。「{{生物学名|ウマ|Equus caballus|馬|en|Horse}}」と入力すると「ウマ(馬、英: Horse, 学名: Equus caballus)」と表示されるとかね。
  • テンプレート化する利点は、G-Soundsさんがおっしゃるような「学名をイタリックにするのを忘れる」を防止したり、なにかあったときに一括して書式を制御できる、など。反面、いまさら生物記事を全部テンプレートに置き換えるのは現実的じゃないだとか、多様な言語表記を何種類も併記しようとすると煩雑になるとか。
  • この手のタグ類で毎度の話になりますが、古いタイプのhtmlの考え方では「斜体にしろ、理由は知らん」という指示だったのが、新しいhtmlの考え方では「学名を表示しろ、方法は任せる」という指示になっていますから、テンプレート化するほうが「いまどき」という感じです。ただ現実問題としてWikipediaは常に最新のhtml作法に追随しているわけではないし、いまさら広範囲で変更するのはしんどいし、「完成の瞬間がない」(いつまでも変化し続ける)という特殊性からすると、どこかの時点でのhtml作法に寄せすぎると、将来的にまた何かが起きるかも、みたいなのがあって・・・。--柒月例祭会話2023年11月21日 (火) 03:43 (UTC)[返信]
ネイさんのおっしゃるように、ミスの防止は現状で充分との考え方も有り得るでしょうね。私の場合は、ミスをしかけたものの、uploadの前に気付いた事は、既述の通りです。
㭍月例祭さんがおっしゃったtemplate化は、1つの解決策かもしれませんね。別に全て置き換えずとも、長い年月に亘って編集が繰り返されてゆく間に、次第にtemplateに置き変わってゆくでしょうから。そして、templateなら変更が必要になれば、templateの側を編集すれば、それで好きなように表示を変えられますから。
ともあれ、11月20日の私の書き込みは、この場所の議論がcloseされていなかったので、思う所を書き込んだ次第です。--G-Sounds会話2023年11月30日 (木) 19:53 (UTC)[返信]