Smart Communication Design Company
ホーム > ナレッジ > Blog > アクセシビリティBlog

Webサイトのアクセシビリティを高めるための方法や国内外の関連情報など、さまざまな角度からWebアクセシビリティに関する話題をご提供します。

当Blogの更新情報は、Twitter経由でも配信しています。興味のある方はぜひ、@mlca11yをフォローしてください。

2020年のWebアクセシビリティ


取締役 木達

gihyo.jpの新春特別企画の一環で、「2020年のWebアクセシビリティ」という記事を、当社アクセシビリティ・エンジニアの中村直樹さんが寄稿しました。昨年まで6年連続で同企画に寄稿してきた黒澤さん（同じく当社アクセシビリティ・エンジニア）に代わっての寄稿となります。是非ご一読いただければと思いますが、内容の紹介がてら記事中の見出しを以下に列挙します。

少しばかり個人的な感想を書かせていただきますと、同記事で私がまず気になったのが、WCAG 2.2に関する言及です。

新規の達成基準の候補については，Potential WCAG 2.2 SCsというタイトルのGoogleスプレッドシートに挙げられており，17の達成基準の候補が挙げられています。WCAG 2.0からWCAG 2.1では達成基準が17増えたわけですから，最大で同規模の分量となることが見込まれます。

達成基準のさらなる充実（追加）は、ユーザーや利用状況の多様性に対し私たちWeb制作者が理解を深め、Webコンテンツをよりアクセシブルにするうえで大変喜ばしいことです。しかしそのいっぽう、新たな達成基準の検証方法をどうするか、検証にかかる時間的・金銭的コストとどう向き合うかなど、悩ましい側面があるのも事実。

その辺りはユーザーエージェントや支援技術、そして検証ツールの進化と歩調を合わせながら、現実的な対応を模索し続けたいところです。誤解を恐れずに言うなら、ガイドラインはガイドラインに過ぎません。WCAGにどこまでどう従うかは、利用する私たちの側に委ねられているのですから。

またWAI-ARIAについては、バージョン1.2の勧告に向けた状況が、記事で紹介されていました。WAI-ARIAは、高度で複雑なWebアプリケーションにとっては特に必要不可欠な存在となって久しく、その充実もまたWCAG同様、Web制作者にとってありがたいもの。ですが、個人的にはMarco Zehe氏が先月お書きになった記事「Call to action: HTML needs more native rich widgets - Marco's Accessibility Blog」の

We should move away from the "ARIA will fix it" mentality and put more effort into "Let's give web authors more accessibility out of the box for richer components", so those sad figures of 97% of inaccessible sites will hopefully drop to a much more satisfactory number in the next five years.

というくだりに賛同します。WAI-ARIAに頼ることなく、ネイティブなHTML要素で必要な実装が実現できればそれに越したことはないわけで......道のりは容易ではないでしょうが、（WAI-ARIAのみならず）HTML仕様の今後の充実にも期待し、また可能な範囲で協力もしていけたらと思いました。

パーマリンク

フォーカスの分類


アクセシビリティ・エンジニア 黒澤

この記事はミツエーリンクスアドベントカレンダー2019 - Qiitaの23日目の記事です。

私はWebページの検証やコンサルティングの業務を多々行っており、開発者とやり取りすることもあります。その際、開発者に「フォーカスを受け取れるように、要素のtabindex属性に-1を設定してください」と伝えると、高い確率で「tabindex属性に-1を設定するとフォーカスを受け取らなくなるのでは？」と返されます。実際のところ、tabindex="-1"はフォーカスを受け取ります。

なぜ、そのような認識の違いが起こるかというと、ある要素がフォーカスを受け取るかどうかや、受け取るかどうかを制御する方法が複雑なためだと考えています。この記事ではその複雑性と、複雑性がどう整理されようとしているかを述べます。

フォーカスを受け取る経路

Webページでは要素がフォーカスを受け取る経路は、ユーザーの利便性や歴史的経緯を踏まえてかなりの種類があります。例えば、次のようなものがありますが、他にもまだまだあります。

要素をクリックしてフォーカスが移動することは一見不自然に見えるかもしれませんが、マウスを使っているユーザーにとって必須ともいえる挙動です。もし、マウスで要素をクリックしてもフォーカスが移動しないなら、テキスト入力欄をクリックしてもフォーカスは移動せず、ユーザーは文字を入力することはできません。マウスユーザーもTabキーを押してフォーカスを移動しなくてはならないはずです。

さて、問題なのはフォーカスを移動させる経路が複数あることだけではなく、その経路が機能するかどうかが個別に制御されていることです。例えば、tabindex="-1"を指定すると、Tabキーを押してもフォーカスを受け取りませんが、他の経路では受け取ります。

<button type="button" tabindex="-1">ボタン</button>
<label>入力欄<input tabindex="-1"></label>

この例ではいずれもTabキーを押してもフォーカスは移動しませんが、クリックするとフォーカスは移動しますし、focus()メソッドを呼び出してもフォーカスは移動します。もっとも、input要素にtabindex="-1"を指定することはまずありませんが、WAI-ARIA Authoring Practices 1.1のMenuのように矢印キーで項目を選ぶUIを実装する場合などはtabindex="-1"を適切な要素に指定する必要があります。矢印キーで項目を選ぶUIは、Tabキーを押してもフォーカスが移動しないようにした上で、矢印キーが押されたことをJavaScriptで検出してfocus()メソッドでフォーカスを移動させているためです。

その一方で、フォーカスを全く受け取らない要素も存在します。

これらの要素はtabindex属性を指定してもフォーカスを受け取りません。

<button type="button" disabled tabindex="0">ボタン</button>
<label>入力欄<input disabled tabindex="0"></label>

このような複雑な挙動・仕組みになっているのは、歴史的な経緯としかいいようがなく、初学者にとって分かりやすいものではありません。

仕様におけるフォーカスの整理

2019年はフォーカス関連の仕様が整理されました（注1）。HTML仕様ではフォーカスを受け取るかどうかが次のように整理されています。

フォーカス可能は理論上フォーカス可能であることを指します。フォーカス可能な要素は少なくともJavaScriptのfocus()メソッドでフォーカスを移動することができます。フォーカス可能でなければ、何をしてもフォーカスは移動しません。前述の無効なフォームコントロールは、そもそもフォーカス可能ではないのです（注2）。

逐次フォーカス可能はTabキーを押した場合にフォーカスが移動することを指します。フォームコントロールやリンクは基本的には逐次フォーカス可能です。div要素などの逐次フォーカス可能でない要素もtabindex属性に0を指定すると逐次フォーカス可能になります（Tabキーを押すとフォーカスが移動します）。逆に、逐次フォーカス可能であってもtabindex属性に-1を指定すると逐次フォーカス可能ではなくなります（Tabキーを押してもフォーカスは移動しません）。なお、逐次フォーカス可能な要素はフォーカス可能です。

クリックフォーカス可能は要素をクリックするとフォーカスが移動することを指します。フォームコントロールやリンクは基本的にはクリックフォーカス可能です。div要素などのクリックフォーカス可能でない要素もtabindex属性に-1を指定するとクリックフォーカス可能になりますし、0を指定してもクリックフォーカス可能になります。tabindex="-1"は要素をクリックフォーカス可能にする指定であるため、フォームコントロールやリンクにtabindex="-1"を指定してもクリックフォーカス可能なままです（クリックするとフォーカスが移動します）。tabindex属性を使ってフォームコントロールやリンクをクリックフォーカス不可能にすることはできません。なお、クリックフォーカス可能な要素はフォーカス可能です。

おわりに

いかがでしょうか。これまで漠然としていたフォーカスに少しは見通しがついたでしょうか。

実際のところ、これでも未整理の問題は多々あります（注3）。ただ、それらの問題も徐々に整理されようとしています。皆さんの開発がより一層シンプルになるようサンタさんにお願いして、筆をおきます。

注

注1：2019年にフォーカス関連の仕様が整理されたのは、カスタム要素やShadow DOMでのフォーカスの扱いを定義するためであり、初学者の理解のためではありません。とはいえ、結果的に初学者にとっても分かりやすくなりました。HTML仕様におけるフォーカスの整理例にはGitHubのプルリクエスト 4768 - Define different types of "focusable" & remove "tabindex focus flagがあります。

注2：無効なフォームコントロールがフォーカス可能でないことはHTML仕様の6.5.2に記載があります。

注3：HTML仕様におけるフォーカス関連の問題はGitHubの課題 4607 - Focus meta-bugにまとまっています。

パーマリンク

PDFのアクセシビリティ対応：入門編


アクセシビリティ・エンジニア 小出

この記事はミツエーリンクスアドベントカレンダー2019 - Qiitaの17日目の記事です。

Webサイトにはアクセシビリティ対応が必要である、ということが浸透するにつれて、サイトに掲載されているPDFをアクセシブルにするにはどうしたらよいでしょうか？というお問い合わせをいただくことが増えてきました。

そこで「WebサイトにおけるPDFとは何か」をあらためて考えつつ、PDFのアクセシビリティ対応について、基本的な内容を簡単に説明したいと思います。

PDFとは

そもそも、PDFとは何を伝えるためのフォーマットでしょうか。
画像であればPNGやSVG、音声であればMP3やAAC、動画であればAVIやMP4などのように、サイトで表現したいコンテンツにはそれぞれ適切なフォーマットが存在します。

PDF（Portable Document Format）は、電子文書のためのフォーマットです。
OSやアプリケーションに依存せずに、ドキュメントを作成したアプリケーションと同一の表示を再現できます（同一性の維持）。

例えばWindowsのMicrosoft Wordで作成されたdocxファイルをMacのApache OpenOfficeで開くと、Windowsとは異なるビジュアルで表示されることがあります。
一方、WindowsのMicrosoft Wordで作成されたPDFファイルは、MacのPDFビューアで開いても表示を再現することができます。
紙の文書のように、テキストだけでなく、レイアウトやデザインのようなビジュアルの同一性も保たれるのがPDFの強みのひとつです。

「PDFのアクセシビリティ対応：入門編」の全文を読む

パーマリンク

国交省の公共交通機関ガイドライン


アクセシビリティ・エンジニア 中村（直）

この記事は、ミツエーリンクスアドベントカレンダー2019 - Qiitaの9日目の記事です。

2019年10月、国土交通省は公共交通機関の移動等円滑化整備ガイドライン（通称：バリアフリー整備ガイドライン）の改訂を行いました（報道発表資料）。

このガイドラインは、公共交通機関（鉄道、バス、旅客船、航空機）について、旅客施設と車両などに対して、主にハード面からどのように交通アクセシビリティを確保すればよいのかについて、重点的に取り扱ってきたものでした。今回の改訂では、第5部「情報提供のアクセシビリティ確保に向けたガイドライン」が新設され、その中の「１．ウェブアクセシビリティについて」「①ウェブサイト等による情報提供」には「考え方」と「ガイドライン」がそれぞれ次のように記載されています。

考え方

障害者等にとって、円滑に旅客施設を利用するためにエレベーターやトイレ等の設備の設置状況や設置位置、受けられるサービスの内容等について、ウェブサイト等により事前に情報を収集することが重要となる。
ウェブサイトについては、文字の大きさ、色使い、コントラスト等の見やすさや、画像、映像、音声情報などを活用した情報の把握のしやすさ、操作のしやすさ等に配慮するとともに、サイト全体としての使いやすさを考慮した構成を検討する必要がある。加えて、障害者や高齢者等を含めた誰もがウェブサイト等で提供される情報や機能を支障なく利用出来るようにするため、ウェブアクセシビリティについての対応も重要となる。
「みんなの公共サイト運用ガイドライン」（総務省）では、公的機関はウェブアクセシビリティに関する日本産業規格である JIS X 8341-3:2016 の適合レベル「AA」に準拠することが求められている。そのため、公共交通事業者等のウェブサイトにおいても、レベル「AA」に準拠することを基本とする。また、レベル「AAA」についても、公共交通事業者等として対応が必要であると考えられる項目については取り組むことが望ましい。
なお、アクセシビリティの確保はウェブコンテンツ全般について求められるものである。公共交通事業者等はウェブアクセシビリティ確保の目標と計画を定め、確実に取り組むことが必要である。また、ガイドラインの趣旨は、各項目の基準に準拠することが目的ではなく、技術上の問題等で記載内容の通りに対応できないものについては、代替手段を検討し利用者の目的を達成することが重要である。

ガイドライン
◎：移動等円滑化基準に基づく整備内容（義務）、○：標準的な整備内容、◇：望ましい整備内容

アクセシビリティ
○障害者等が円滑にウェブサイト等を利用し必要な情報を得られるようにするために、JIS X 8341-3:2016 に基づき、ウェブアクセシビリティを確保する。

端的に言ってしまえば、JIS X 8341-3:2016適合レベルAA準拠+追加する達成基準について取り組むことが言及されています。バリアフリー整備ガイドラインでの「○：標準的な整備内容」の位置付けが「社会的な変化や利用の要請に合わせた整備内容で、積極的に整備を行うことが求められる」とされているので、義務的なものはありません。しかし、このガイドラインに書かれていることのすべてを満たそうとすると、みんなの公共サイト運用ガイドライン（2016年版）で国・地方公共団体に望まれているJIS X 8341-3:2016適合レベルAA準拠以上の対応を行う必要があることになります。Webサイト全体に対して、バリアフリー整備ガイドラインを最終目標とするには、かなり険しい道のりであるということは言えそうです。

その一方で、令和元年度第１回「移動等円滑化のために必要な旅客施設又は車両などの構造及び設備に関する基準等検討会」で示されていた当初の改訂案では、現在のガイドラインとはやや異なった書きぶりとなっていました。（資料５　ウェブアクセシビリティ確保に向けたガイドラインの改訂（案））

この改訂案では、特に適合レベルAAについて、「基本：優先的に取り組む項目」と「推奨：取り組むことが望ましい項目」にわけられ、段階的に取り組む方策が示されていたのが特徴です。適合レベルAAについて、推奨とされていた達成基準は次の通りです。

JIS X 8341-3:2016の適合レベルAAについては、全部で13の達成基準が示されていますが、そのうちほぼ半分の6つについて、「推奨」とするものでした。これにより、段階的にWebアクセシビリティに取り込んでいこう、という改訂案作成者の意図が見えるものとなっていました。

適合レベルAAをこのように「基本」と「推奨」に分割するのが妥当なのかどうか、というのは議論の余地があるとは思いますが、少なくとも当社での「標準対応」でも音声や動画といったメディアファイルについては、例外としています（ウェブコンテンツ・アクセシビリティ・ガイドライン（WCAG）2.1への標準対応の開始について）。

仮に何もWebアクセシビリティに対応していない段階からこれから取り組みはじめるとして、改訂案の「基本」のみに取り組むことで、動画や音声については後回しにしつつ、適合レベルAと一部の適合レベルAAを達成することが改訂案ではできたわけです。これは妥協的とも取られるかもしれませんが、ある意味では現実的であったと個人的には考えます。

残念ながら「総合的な判断」（国交省担当官談）により、この改訂案どおりにはガイドラインは制定されることはなかったわけですが、もし改訂案どおりに制定されることになっていたならば、JIS X 8341-3:2016適合レベルAAより緩やかなガイドラインが示される可能性もあったわけで、その意味ではやや残念な形になったと個人的には感じています。

とはいえ、公共交通機関に対して、国・地方公共団体と同様に、JIS X 8341-3:2016適合レベルAA準拠を目標とすることが明確に示されたのは間違いありません。公共性の高い民間事業者に対するひとつの指針として、大きな一歩を踏み出したと言えるでしょう。これを機に今後、公共交通機関と同様の公共性の高い事業分野にもWebアクセシビリティをという声がもしかしたら高まるかもしれません。思いつくだけでも、例えば、電気・ガス・通信などのインフラ分野、銀行等の金融分野、大学等の教育分野、病院等の医療分野などといった分野にも国・地方公共団体に準じたWebアクセシビリティが求められる時代が来る......のかもしれません。

この国交省のガイドラインがWebアクセシビリティ界隈にどういう影響を与えるのか、個人的に注目していきたいと思っています。

パーマリンク

企業がWebアクセシビリティに取り組むべき理由


取締役 木達

去る10月8日、Global Business Hub Tokyoで行われたシックス・アパート株式会社主催のイベント「SAtisfaction 2019」で、私は企業がWebアクセシビリティに取り組むべき理由と題した講演をさせていただきました。

そしてつい先日、同講演のレポート記事、「ビヨンセの公式サイトも訴えられた」企業Webサイトがアクセシビリティに取り組むべき理由とは？がWeb担当者Forumに掲載されました。当日お話しした内容をかなり精緻に書き起こしていただいており、スライドを見ただけでは伝わらない・わかりにくい部分も、同記事をお読みいただくことで解消できるかと思います。

改めてイベントにご参加くださった皆様、イベントを主催されたシックス・アパートの皆様には、厚く御礼申し上げます。ありがとうございました。

講演の冒頭で触れた、アメリカでのWebアクセシビリティ関連訴訟について若干補足させていただきますと、比較的最近にも注目に値するニュースがありました。Webサイトやモバイルアプリから好みのピザを注文できなかったために全盲のGuillermo Robles氏より訴訟を受けたドミノ・ピザ社が、WebやアプリはADAの適用対象外とするよう合衆国最高裁判所に求めていた訴えが、退けられたのです（U.S. Supreme Court Won't Hear The Domino's Case (Hooray!) - Law Office of Lainey Feingold参照）。

企業がWebアクセシビリティに取り組まないでいることで、訴訟を起こされるリスクが高まることは今後ますます、避けられないでしょう。それはインターネットの、Webの普及と密接にリンクしています。障害の有無にかかわらず、誰もがさまざまな状況でWebにアクセスできる・アクセスする必要のある時代だからこそ、Webサイトを運用する側がアクセシビリティ向上に取り組む必要性が強まっているのです。

もちろん法令を遵守し、訴訟リスクを下げることだけがWebアクセシビリティ向上の目的、動機とはなり得ません。そこには多くのメリット、とりわけ機会損失を最小化し、コンバージョンの取りこぼしを減らすという、ビジネス的に極めて前向きな理由もあります。企業のWeb担当者の皆様には、是非その点をご理解いただいたうえで、それぞれに取り組みを始めるなり、維持・強化していただければありがたく思います。

パーマリンク

Webにおける数式と数式の読み上げを取り巻く環境について


アクセシビリティ・エンジニア 中村（直）

Webで数式の表現をするにあたっては、仕様上はMathML（現在のW3C勧告はMathML Version 3.0 2nd Edition）と呼ばれるマークアップ言語で表現できることになっています。かつては、MathPlayerのようなプラグインを別途インストールしなければ表示することができなかったことや、古いXHTMLでは専用のDOCTYPE宣言を用いなければならなかったこともあり、マイナーな存在であったと言えます。しかし近年、実装面では昨年にIgalia社が米国の標準化団体であるNISOから資金援助を受け、ChromiumへのMathMLの（再）実装を試みており、いよいよ実装目前のところまで差し掛かってきました（MathML in Chromium: Upstream process started）。また、ブラウザーのMathML実装状況については、同じくIgaliaのMathML and Browsersのレビュー記事が参考になります。

また、仕様面においては、W3C HTML5勧告の時点でSVGと同様にMathMLが既に取り込まれています。そして、Igalia社のエンジニアFrédéric Wang氏がMathML in HTML5 - Implementation Noteを公表したことを1つのきっかけとして、W3CでMathML Refresh Community Groupが立ち上がり、現在ではこのグループでMathML 3をブラッシュアップした仕様群の議論が行われています。

ところで、数式をスクリーンリーダーで読み上げさせるとどうなるのか？というところも興味深いところであります。二次方程式の解の公式をWindows10のナレーターと、NVDAに読み上げさせてみました。

MS Word + ナレーターの環境では次のように読み上げました。

x　イコール　分子　マイナス　b　プラスマイナス　平方根の　b二乗　マイナス　4ac　最後平方根　最後分子　割る　2a

Firefox + NVDA + MathPlayerでは次のように読み上げられました。（NVDA 2019.2.1 User Guideの7章では、MathPlayerのインストールが必要とのことです）

x　イコール　ス　ザ　フラクション　ウィズ　ニューマレーター　
ネガティブ　b　プラス　オーアール　マイナス　b　スクエアード　マイナス　4ac　アンド　デノミネーター 2a

NVDAスピーチビューアーでは次のように出力されました。（改行を調整しています）

x equals 
the fraction with numerator 
negative b plus or minus 
the square root of 
b
squared 
minus 4 ac 
 
and denominator 
2 a

残念ながら、英語として出力されてしまっています。

MS Word + NVDAや、Firefox + ナレーターの例が記載されていないことに気づいた方もいるかもしれません。これらの組み合わせについては筆者の環境でうまく読み上げを行うことができませんでした。試したのはWindows上のナレーターとNVDAという限定された組み合わせではありますが、スクリーンリーダーによるそもそもの読み上げが環境に依存する状況であることは言えそうです。

さて、ナレーターではうまく数式を読み上げているように見えますが、本当にうまく読み上げられていると評価することができるのか、という疑問があります。振り返ってみると体系的に数式の読みというのを教育機関で習った記憶が少なくとも筆者はありません。そこで、山口ら(1996)による『日本語による数式読み上げ法の基本構成について』をあたってみました。

この論説では、視覚障害学生が理数系の高等教育を受けるに当たって、日本語での数式の読みが確立されていない問題を指摘し、10項目による読み上げ法の提案を行っています。その詳細についてはここでは紹介しませんが、前述の二次方程式の解の公式ですと、2つの読みを提案しています。1つは墨字を併用できる学生を想定した「簡略読み上げ」で、

x　イコール　マイナスb　プラス・オア・マイナス　平方根・オブ　bの2乗　マイナス4ac　オーバー　2a

となります（読みやすさのためにスペースを設けています）。もう1つは「厳密読み上げ」で、分数などの記号の範囲を明示するもので、

x　イコール　分数　マイナスb　プラス・オア・マイナス　平方根・オブ　bの2乗　マイナス4ac　根号終了　オーバー　2a　分数終了

となります。ナレーターの読みはどちらかというと、「厳密読み上げ」に近しいものであると言え、もっともらしい読み上げであると言えそうです。

山口らによれば、米国の多くの大学では、初年次に"College Algebra"（代数学）が設置されており、初等的なものを含めすべての数学記号に対し、英語による読み方が示されている、とのことです。College Algebraで検索すると出てくるサイトのとあるページでは"In words"というフレーズがあり、確かにどう読むのかということが解説されているようです。

まとめますと、Web上の数式の扱いは、ChromiumにMathMLが再び実装されるまで秒読みとなっており、大きく前進する気配があります。その一方で、スクリーンリーダーによる読み上げはまだまだ途上であり、また日本語固有の問題として、どのように読み上げればよいかが確立されていないという問題があります。山口らが主張するように、視覚障害のあるなしにかかわらず、数式の読み上げの統一は教育に一定の効果があると考えられます。日本語による統一的な数式読み上げ法の確立が望まれるところです。

パーマリンク

axe-core 3.4がリリースされました


アクセシビリティ・エンジニア 畠山

axe-core 3.4.0がリリースされました。

つい先日axeのブラウザー拡張機能にベータ版の新機能が登場したことを本ブログでご紹介したばかりで、こんなにすぐにまた新しいニュースをお届けできることを嬉しく思います。

axe-coreについては、以下の記事もあわせてご参照ください。

本記事では、axe-core 3.4の変更点をいくつかご紹介します。

ローカライゼーション

axe-core 3.4から、さらに使用可能な言語が増えました。現時点では、以下の6つの言語を使用できます。

この中でもスペイン語とポルトガル語（ブラジル）は新しく追加された言語です。日本語訳に関わる一員として、使用可能な言語が増えていくことはとても喜ばしいです。

新ルール：aria-roledescription

aria-roledescriptionという新しいルールが追加されました。

これまでaria-roledescriptionという属性に関するテストは、aria-allowed-attrというルールに含まれるテストで実施されていました。個別のルールとして追加されたことで、より正確にaria-roledescriptionに関するテストを実施できるようになります。

廃止されたルール

axe-core 3.4からは、以下の3つのルールが廃止されました。

checkboxgroupとradiogroupは、関連するチェックボックスやラジオボタンをグループ化することを求めるルールです。このルールではグループ化にfieldset要素を用いることを推奨していましたが、他の方法がより適している場合もあるため、axe-coreが不正確な結果を報告しないよう廃止したとのことです。

video-descriptionというルールはvideo要素にtrack要素による音声解説をつけることを求めるルールです。映像などのメディアコンテンツに音声解説が必要であるという前提は変わりませんが、ブラウザーによるtrack要素のサポートが不十分であるため、今回廃止となりました。

これらの廃止されたルールはaxe-core 3.4の時点ではデフォルトで無効化されています。また、axe-core 4.0からは完全に削除されるそうです。

まとめ

axe-coreはオープンソースで開発されており、今も世界中の方々が貢献しています。興味のある方はぜひ貢献してみてはいかがでしょうか。

今回ご紹介した点以外の変更については、axe-core 3.4.0のリリースノートをご確認ください。

パーマリンク

Pick Up