我々、一般の企業にとって最も重要な改正のポイントとしては、これまで努力義務(意味的には「Should / するべき」)とされていた、事業者による「合理的配慮の提供」が、義務化(意味的には「Must / しなければならない」)されるという点でしょう(なお、国(行政機関など)については改正前から法的義務とされています)。
弊社の専門分野は法律や法務ではないため、この改正法についての詳しい解説、あるいは具体的な事例に関する法的な解釈などについてアドバイスや情報提供を行う立場ではありませんが、Webページやアプリケーションにおける、アクセシビリティを専門分野としている関係から、Webサイト等の運用における「合理的配慮の提供」についてはクライアント様をはじめ、多くの方からよくご相談いただく内容であり、現行法はもちろん、今回の改正法施行にも注目し、適切、かつ正しい情報提供ができるよう、努めております。
そこでこの記事では、「改正 障害者差別解消法」に関する情報を整理してお届けしてみたいと思います。
まず、最も基本的な部分ですが、内閣府のWebサイトより、「障害者差別解消法」、および「改正 障害者差別解消法」に関連する広報資料を下記にまとめます。簡単に概要を理解したいという方はこれら資料をまずは確認してみるとよいでしょう。
『チラシ「障害者差別解消法が改正に 事業者にも合理的配慮の提供が義務化されます」』以外については、2016年4月1日の施行前から公開されていたものです。
法律の全文を読む前に、なぜこの法律が施行されるに到ったのか、どのような意図があるのかについては、下記リンク先に記載されていますので、そちらを一読されるのがよいと思います。
現行、改正法問わず、障害者差別解消法の大きなポイントとしては以下の点が挙げられます。
基本方針ではこれら大枠の考え方や、法律が適用される範囲、あるいは求める対応などについてまとめられています。
この基本方針についても、改正に伴い変更が入っていますので、改正法の基本方針を確認したいところですが、本記事執筆点ではWebページ(HTML)としては公開されていません。
PDF形式などでは閲覧可能で、前述した内閣府、「障害を理由とする差別の解消の推進」ページの「基本方針」セクションにリンクがありますので確認してみてください。
もし、改正前後で基本方針がどのように変わったのかを確認したいという用途であれば、下記のPDFファイルが適していますので参考までにリンクを掲載しておきます。
現行の「障害者差別解消法」が具体的にどのような内容なのかを確認したいという方は、法律の全文を読んでみることをお勧めします。長大な文章ではありませんのですぐに読むことができるでしょう。
基本方針と同じページからリンクが張られていますので、Webページとして閲覧可能です。
改正 障害者差別解消法は、現行の法律(上記リンク)に一部改正を加えたものですが、この改正箇所について改正前後で比較をしたい場合は、下記のPDFが便利です。
リンク先をご確認頂くとわかると思いますが、一般的な企業にとっては、「第8条」の改正が関係します。
それまで社会的障壁の除去の実施について必要かつ合理的な配慮をするように努めなければならない。
となっていたものが、社会的障壁の除去の実施について必要かつ合理的な配慮をしなければならない。
と変更されていますね。
これが、「合理的配慮の提供が義務化された」という話の具体的な根拠となる条文の改正ということになります。
詳しくは上記に示した各リンク先をご覧頂くのがよいと思いますが、重要な用語について簡単にまとめておきます。
障害者というと「障害者手帳を持っている人のことですか?」と思われる方もいらっしゃるかもしれませんが、法律が定義する障害者は下記の通りです。
対象となる障害者は、法第2条第1号に規定する障害者、即ち、身体障害、知的障害、精神障害(発達障害及び高次脳機能障害を含む。)その他の心身の機能の障害(難病等に起因する障害を含む。)(以下「障害」と総称する。)がある者であって、障害及び社会的障壁により継続的に日常生活又は社会生活に相当な制限を受ける状態にあるものである。これは、障害者基本法第2条第1号に規定する障害者の定義と同様であり、いわゆる「社会モデル」の考え方を踏まえている。したがって、法が対象とする障害者の該当性は、当該者の状況等に応じて個別に判断されることとなり、いわゆる障害者手帳の所持者に限られない。
「改正 障害者差別解消法 - 基本方針」より引用
最後の部分に書かれているとおり、障害者手帳の所有者に限定されるものではありません。
『事業者にも合理的配慮の提供が義務化されます』などというように、「事業者」という言葉が出てきますが、法律上の定義は下記の通りです。
対象となる事業者は、商業その他の事業を行う者(地方公共団体の経営する企業及び公営企業型地方独立行政法人を含み、国、独立行政法人等、地方公共団体及び公営企業型以外の地方独立行政法人を除く。)であり、目的の営利・非営利、個人・法人の別を問わず、同種の行為を反復継続する意思をもって行う者である。
したがって、例えば、個人事業者や対価を得ない無報酬の事業を行う者、非営利事業を行う社会福祉法人や特定非営利活動法人も対象となり、また対面やオンラインなどサービス等の提供形態の別も問わない。
「改正 障害者差別解消法 - 基本方針」より引用
つまり何らかの事業を行っていれば、業界を問わず、すべて対象ということです。
「合理的配慮」というのは何ですか?ということについては、下記のように基本方針に定義されています。少し長いですが引用します。
「合理的配慮」は、「障害者が他の者との平等を基礎として全ての人権及び基本的自由を享有し、又は行使することを確保するための必要かつ適当な変更及び調整であって、特定の場合において必要とされるものであり、かつ、均衡を失した又は過度の負担を課さないもの」と定義されている。
(中略)
合理的配慮は、障害の特性や社会的障壁の除去が求められる具体的場面や状況に応じて異なり、多様かつ個別性の高いものである。また、その内容は、後述する「環境の整備」に係る状況や、技術の進展、社会情勢の変化等に応じて変わり得るものである。
合理的配慮は、行政機関等及び事業者の事務・事業の目的・内容・機能に照らし、必要とされる範囲で本来の業務に付随するものに限られること、障害者でない者との比較において同等の機会の提供を受けるためのものであること、事務・事業の目的・内容・機能の本質的な変更には及ばないことに留意する必要がある。その提供に当たってはこれらの点に留意した上で、当該障害者が現に置かれている状況を踏まえ、社会的障壁の除去のための手段及び方法について、当該障害者本人の意向を尊重しつつ「(2)過重な負担の基本的な考え方」に掲げた要素も考慮し、代替措置の選択も含め、双方の建設的対話による相互理解を通じて、必要かつ合理的な範囲で柔軟に対応がなされる必要がある。
「改正 障害者差別解消法 - 基本方針」より引用
ここで「環境の整備」という言葉が出てきますが、環境の整備は下記のように記述されています。ここでアクセシビリティの話が出てきていますね。
環境の整備の基本的な考え方
法は、個別の場面において、個々の障害者に対して行われる合理的配慮を的確に行うための不特定多数の障害者を主な対象として行われる事前的改善措置(施設や設備のバリアフリー化、意思表示やコミュニケーションを支援するためのサービス・介助者等の人的支援、障害者による円滑な情報の取得・利用・発信のための情報アクセシビリティの向上等)を、環境の整備として行政機関等及び事業者の努力義務としている。環境の整備においては、新しい技術開発が投資負担の軽減をもたらすこともあることから、技術進歩の動向を踏まえた取組が期待される。また、ハード面のみならず、職員に対する研修や、規定の整備等の対応も含まれることが重要である。「改正 障害者差別解消法 - 基本方針」より引用
つまり、「合理的配慮を提供する」ということは、障害者から求められたとき、事業者にとって業務に大きな支障が出たり、過度な負担とならない範囲で、障害者でない人と同等の機会の提供が行えるように配慮してくださいということになります。
これは例えば、お店の前に階段があって、車椅子のお客さんがお店に入れなくて困っていると申し出があった場合、「階段にスロープを臨時で設置して、車椅子で上るのをお店のスタッフの方が手伝ったり」「店舗内で車椅子の移動に支障がある障害物を一時的に移動したり」といった対応が挙げられます。
一方で、スタッフが1人で運営しているお店の、一番混み合う時間帯に、事前の申し合わせもなく上記のような対応を求められたとして、「他のお客さんの対応があるので今は難しいです。少しお待ち頂けますか?」といった対応をするのも、「均衡を失した又は過度の負担を課さない」「双方の建設的対話による相互理解を通じて、必要かつ合理的な範囲で柔軟に対応」という部分を解釈すれば妥当でしょう。
当然ながら、「障害者の方に求められたら、なにがなんでも要望通りにしろ」などという無茶な話ではありませんので、その点は誤解しないように注意してください。
その上で、例えばお店をリニューアルするような機会に「階段の一部をスロープ化する工事をする」、あるいは「店舗内の什器などの配置を、車椅子の方が来店しても問題ないよう、余裕のあるレイアウトに変更しておく」といったことは、「環境の整備」に該当しますので、可能であれば徐々に取り組んでいくとよいと思います。
基本方針にも書かれていますが、合理的配慮は、「特定の利用者(障害者)に対して、個別の状況に応じて提供される措置」であり、一方の「環境の整備」は、「不特定多数の利用者(障害者)向けに、事前に改善措置を実施しておく」という話になります。
余談ですが、それを踏まえて、Webサイトのアクセシビリティ対応の話をしますと、これは不特定多数の利用者に対して、情報にアクセスしやすくするための継続的な取り組みであり、言い換えれば、環境整備のための有効な施策となります。
弊社としましても、この機会に新たにアクセシビリティ対応に興味をもち、実践される企業、団体様が増えることを願っています。
具体的に、合理的配慮の提供に関する事例が見てみたい、という方には下記が参考になります。こちらもリンク先は内閣府のWebサイトです。
また、内閣府が提供する下記のサイトでは、上記の事例集を、条件に応じて検索して閲覧することができます。
例えば、上記で紹介されている事例の中には、下記のようなものがあります。
1-(1)-3
事例: 書類等にマーカーで線を引いて説明をされても、色が同じに見えてしまうので分からない。対応: 該当箇所に数字や下線、波線 等の印をつけて説明をした。
上記は行政機関の窓口における対面でのやりとりで発生した事例ですが、実は、Webページにおいても同様の問題が発生します。
「ウェブコンテンツ・アクセシビリティ・ガイドライン(WCAG - Web Content Accessibility Guidelines)」や「JIS X 8341-3:2016」の「達成基準 1.4.1」には、「色の使用 / Use of Color (Level A) 」という達成基準があります。
これは、わかりやすく簡単に言うと、「色の違いに依存して情報を伝えようとすると、それが正しく認識できない利用者もいますよ」という話なのですが、まさに事例と同様、Webコンテンツにおいても、線や背景の色、あるいは文字の色など、「色」のみに依存して情報を伝えようとすると、色を正しく認識できない利用者にとっては理解できない内容になってしまうことがあります。
そのため、上記事例における対応のように、色だけに依存せず、異なる種類の下線や枠線を組み合わせたり、アイコンのデザインなどと組み合わせて情報を伝える必要があり、そのことがアクセシビリティガイドラインにも明記されているということです。
つまり、前述した「環境整備としてのアクセシビリティ対応」に日頃からきちんと取り組んでおくことで、自然とこのような事例に対して問題解決がされている、という状態を作ることができるわけです。
最後に少し余談にはなりますが、今回の改正 障害者差別解消法の施行に関連して、一部で「合理的配慮の提供」として、特定のアクセシビリティガイドライン、例えば WCAG や JIS X 8341-3:2016、もしくはそれらガイドラインにおける、特定の適合レベルに適合、準拠することが「義務化される」といった誤った情報が散見されるようです。
前述したとおり、アクセシビリティ対応は環境整備(不特定多数に対する事前的な改善措置)に該当すると考えるのが妥当でしょう。また、アクセシビリティガイドラインのある適合レベルに適合、準拠したからといって、合理的配慮の提供を行う機会がゼロになるのかというとそんなことはありません。
合理的配慮とは、「特定の利用者(障害者)に対して、個別の状況に応じて提供される措置」ですから、Webサイトがアクセシビリティガイドラインに適合、準拠していようが、していなかろうが、障害者の方から「ここがどうしても使えないのでなんとかして欲しい」と言われれば、合理的配慮の提供義務が生じます(その提供方法がWebサイトの修正、改修とは限りません)。
また、弊社としても、環境整備としてアクセシビリティ対応に取り組んで頂くこと自体は強くお勧めしますが、アクセシビリティ対応は、ある時点で、特定のアクセシビリティガイドラインの、特定の適合レベルに適合、準拠すればそれで全部終わり、というような短期的な取り組みではありませんし、試験結果でエラーがなかったからといって、それがすべての利用者(障害者を含む)にとって、100% 使いやすく、わかりやすいというお墨付きをもらったわけではない、という点も忘れてはいけません。
それらを正しく認識した上で、環境整備としてのアクセシビリティ対応に興味を持って頂けたのなら、アクセシビリティ対応をお手伝いしている弊社としてもうれしい限りです。
また、自社に提供可能な合理的配慮とは?という点については、日頃から、Webサイトの運用に関わる方々の間で情報収集、共有したり、ディスカッションして共通認識を持っておくということも大切です。その中で、問い合わせ対応の体制を整えたり、マニュアルを整備したりといった、環境整備面での課題、施策が洗い出されることも多いと思います。
ぜひこの機会に、できるところから始めてみてください。そのきっかけとして、本記事が少しでもお役に立てば幸いです。
弊社では、「Webアクセシビリティ対応(適合・準拠)サービス」「Webアクセシビリティ チェック(評価)サービス」「Webアクセシビリティコンサルティング」などの、Webアクセシビリティ関連サービスを提供しています。
また、具体的な要件は決まっていないが、Webアクセシビリティ対応などについて相談したいことがある、という企業様向けに、「オンラインでのスポットコンサルティング」も提供しておりますので、お気軽にご相談ください。
バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2024年3月13日 18:12 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/433/ です。
]]>今回の改定による、各適合レベルごとの達成基準数の変動(WCAG 2.1 → WCAG 2.2)は下記の通りです。トータルでは9つの達成基準が新たに追加されています。
勧告から少し時間が空いてしまいましたが、過去にWCAG 2.1が勧告された際にも同様のコラムを書かせていただいたこともあり、今回、WCAG 2.2に関しても、新たに追加された達成基準について、簡単にではありますが解説をしてみたいと思います。
]]> WCAG 2.2で追加された達成基準まずはWCAG 2.2で新たに追加された達成基準を確認してみましょう(達成基準の日本語訳は弊社によるもの)。前述の通り、9つの達成基準が追加されています。
簡単にですが、各項目をWCAG 2.1の原文とあわせて解説していきます。
原文:
When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.
この達成基準の主な目的は、キーボードのユーザーがウェブサイトを操作する際に、現在フォーカスしている要素が見えるようにし、それによってユーザーが容易に操作できるようにすることです。フォーカスが「隠されない」ことを保証することで、すべてのユーザーがウェブサイトをより簡単に使用できるようになります。
具体的にはフォーカスが可視化されていること、さらに、その可視化されたフォーカスが、他のコンテンツ(例えば画面の上部や下部に固定されることで他の要素に覆い被さるように表示されるヘッダやフッタのようなものや、ポップアップ、オーバーレイなど)によって隠されていないことが求められますが、最低限、フォーカスの一部でも表示されていればこの達成基準は満たすことができます。
原文:
When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.
前述した「達成基準 2.4.11 隠されないフォーカス(最低限)」をより強化した達成基準です。可視化されたフォーカスが、他のコンテンツによって、一部分すら隠されることなく、完全に表示されることが求められます。
原文:
When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:
- is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and
- has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.
Exceptions:
- The focus indicator is determined by the user agent and cannot be adjusted by the author, or
- The focus indicator and the indicator's background color are not modified by the author.
この達成基準の主な目的は、キーボードのユーザーがウェブサイトを操作する際に、現在フォーカスしている要素を視覚的に確認しやすくし、それによってユーザーが容易に操作できるようにすることです。具体的には、フォーカスインジケータに対して、下記の要件が求められています。
この達成基準を満たそうとした場合、一般的なブラウザソフトが標準で提供するフォーカスインジケータでは不十分になる場合があります。ウェブサイト制作者は、事前にフォーカスインジケータについてもデザインや実装ルールを定めておく必要があるでしょう。
原文:
All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.
ドラッグ操作を必要とする機能は、ドラッグ操作が不可欠な場合、あるいはその機能がユーザーエージェントによって決定されており、ウェブサイト制作者側では変更できない場合を除いて、シングルポインターを使用してドラッグなしで操作できる必要があるとする達成基準です。
この達成基準の目的は、特定の操作(マウスによるドラッグ操作)に依存しない、別の操作方法を提供することで、ユーザーがウェブサイトを操作できなくなることを防ぎます。
原文:
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:
- Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;
- Equivalent: The function can be achieved through a different control on the same page that meets this criterion;
- Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
- User agent control: The size of the target is determined by the user agent and is not modified by the author;
- Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
ポインタ入力のターゲットとなる要素のサイズは、例外を除き、少なくとも24×24 CSSピクセル以上であることを求める達成基準です。ポインタ入力のターゲットとなる要素とは、例えばボタンや入力欄、チェックボックスといった、ユーザーがマウスポインタで操作する要素のことです。
ただし、その要素自体は、最低サイズを満たさない場合でも、下記に該当する場合は例外が認められます。
原文:
If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user:
- Human contact details;
- Human contact mechanism;
- Self-help option;
- A fully automated contact mechanism.
ウェブサイト上で下記のようなヘルプ機能が提供される場合は、同一ウェブサイト上のどのページにおいても、一貫した表示(例えば表示する場所やラベル、見た目などを統一する)を行うことを求めた達成基準です。これにより、ユーザーがヘルプ機能を見つけやすくします。
達成基準で挙げられているヘルプ機能としては下記があります。
原文:
Information previously entered by or provided to the user that is required to be entered again in the same process is either:
- auto-populated, or
- available for the user to select.
Except when:
- re-entering the information is essential,
- the information is required to ensure the security of the content, or
- previously entered information is no longer valid.
同一プロセス内でユーザーによって以前に入力または提供された情報が再度入力を求められる場合、その情報が自動入力されるか、ユーザーが選択できるようにすることを求める達成基準です。
入力のために記憶する必要のある情報は、認知や記憶することが困難なユーザーにとって大きな障壁となりますが、この負担を軽減することが目的です。
例えば、オンラインの購入プロセスにおいて、ユーザーが配送先住所を入力した後、請求先住所が同じである場合には、簡単な操作で、その情報が自動的に請求先住所フィールドに反映されるような実装や、ユーザーがドロップダウンメニューやリストから選択することで、以前に入力した情報を再利用できるようにするような実装が考えられます。
ただし、ユーザーによる情報の再入力が不可欠な場合、コンテンツのセキュリティを確保するために必要な場合、または以前に入力された情報が、もはや有効でない場合は例外とします。
原文:
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:Alternative
Another authentication method that does not rely on a cognitive function test.
Mechanism
A mechanism is available to assist the user in completing the cognitive function test.
Object Recognition
The cognitive function test is to recognize objects.
Personal Content
The cognitive function test is to identify non-text content the user provided to the Web site.
ログインなど、認証プロセスの任意のステップにおいて、認知機能テスト(パスワードの記憶、テキストの転写や計算の実行、あるいはパズルの解決など)に依存した認証方法を求めないという達成基準です。このような作業は、認知や記憶することが困難なユーザーに非常に大きな負担、または不可能な負担を課す場合があります。
認知機能テストに依存しない認証方法としては、例えば、生体認証(指紋や顔認証など)やセキュリティキーによる認証、電子メールやSMSに対して、ワンタイムのログイン用コード、あるいはリンクを送信する方法などが挙げられますので、そのような認証方法のみが使用されている、もしくは代替手段として提供されている場合はこの達成基準を満たすことができます。
一方で、ごく一般的な、ユーザー名、パスワード、あるいは二要素認証システムからの認証コードなどを入力させる(認知機能テストに依存するとされる)ログインフォームなどであっても、ブラウザソフトや、サードパーティ製のパスワードマネージャーから各情報を自動入力(オートフィル)できたり、コピー・アンド・ペーストで入力できる場合、あるいは、二要素認証アプリからコピーした認証コードをペースト入力できる(つまり、それらを覚えたり、書き写したりする必要がない)ような場合は、この達成基準を満たすことができます。
これらは、「ユーザーが認知機能テストを完了するのを補助する機能が提供されている」と見なされるからですが、上記以外でも、ユーザーが認知機能テストを完了するのを補助する機能が提供されていると解釈できる場合は、この達成基準を満たせます。
なお、この達成基準においては、オブジェクト(例えば画像や動画、音声など)の認識、あるいはユーザーによって提供されたテキスト以外のコンテンツの認識を、認知機能テストを代替する認証方法として認めていますが、後述する「達成基準 3.3.9 アクセシブルな認証(高度)」においては、このような認証方法は認められません。
原文:
A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:Alternative
Another authentication method that does not rely on a cognitive function test.
Mechanism
A mechanism is available to assist the user in completing the cognitive function test.
達成基準の内容としては前述した「達成基準 3.3.8 アクセシブルな認証(最低限)」と同様ですが、この達成基準においては、認知機能テストに依存しない認証方法が代替手段として提供されている、もしくは、ユーザーが認知機能テストを完了するのを補助する機能が提供されている場合のみ、達成基準を満たすことができます。
ポイントとして、WCAG 2.2 では、WCAG 2.0 から存在する「達成基準 2.4.7 フォーカスの可視化」をさらに進め、その表示方法やコントラスト比などについても達成基準が設定されていますが、キーボードフォーカスの可視化は、普段、マウスしか使用していないウェブサイト制作者が見落としがちな部分です。
実際に弊社でアクセシビリティ試験を実施していても、多くのウェブサイトでフォーカスインジケータが非表示になっているケースも多く、デザインプロセスや実装ガイドラインの策定時において、明確にルール化しておくことをお勧めする部分でもあります。是非、WCAG 2.2で追加された達成基準も参考に、デザインガイドラインや実装ルールを再確認してみてください。
また、「達成基準 3.3.8 アクセシブルな認証(最低限)」、「達成基準 3.3.9 アクセシブルな認証(高度)」が該当しますが、いまだに、パスワード入力欄をコピー・アンド・ペースト禁止にするような間違った実装が多くのウェブサイトで見うけられます。
この機会に、このような実装がいかにユーザーに負担を強い、かつ場合によっては複雑で覚えにくいパスワードを設定することを忌避させ、結果としてアクセシビリティだけでなく、セキュリティも低下させている可能性を、改めて認識する必要があるのではないかと考えます。
弊社では、「Webアクセシビリティ対応(適合・準拠)サービス」「Webアクセシビリティ チェック(評価)サービス」「Webアクセシビリティコンサルティング」などの、Webアクセシビリティ関連サービスを提供しています。
これら各サービスにおける「WCAG 2.1」や「WCAG 2.2」への対応についてもご相談いただけますので、お気軽にご連絡ください。
バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2024年2月21日 16:23 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/432/ です。
]]>その中で、定期的に頂くのが、サードパーティの JavaScript などをウェブサイトに読み込むことによって、ウェブサイトのアクセシビリティを向上させるという名目で提供される、所謂「アクセシビリティオーバーレイ」についてのご質問です。
具体的にはアクセシビリティオーバーレイを導入することで、例えば WCAG や JIS X 8341-3:2016 といった、特定のアクセシビリティガイドラインに適合、あるいは準拠することができるのか、といったご質問になりますが、今後も同様のご質問を頂くことを踏まえ、ここに弊社の見解をまとめておきます。
まず、結論から申し上げますと、弊社は他の企業、団体様が提供するアクセシビリティオーバーレイ、およびそれに関連するようなサービスについて、その効果を評価、評論したり、あるいは導入をお勧めする、逆に導入は避けるべきであると積極的に働きかけるような立場にはございませんので、最終的にはお客様のご判断にお任せしております。
一方で、アクセシビリティオーバーレイを導入することで、簡単にアクセシビリティ対応が完了する、つまり特定のアクセシビリティガイドラインに準拠することができるといった喧伝、あるいは、国内における「障害を理由とする差別の解消の推進に関する法律(所謂「障害者差別解消法」)」を根拠に、アクセシビリティ対応がまるで義務であるかのように不安を煽り、アクセシビリティオーバーレイの導入を含む、アクセシビリティ関連サービスを売り込むようなマーケティング手法に対しては明確に否定的な立場ですし、異議を唱えます。
ウェブアクセシビリティを専門分野とする立場からは、少なくとも現在の技術において、アクセシビリティの問題を解決する手段となり得る、アクセシビリティオーバーレイは存在しないと考えます。その意味では、「Overlay Fact Sheet」に弊社自体は署名していないものの、その内容には賛同していると言えるでしょう。
弊社としましては、お客様に対して、安易に問題解決のための銀の弾丸をお求めになるのではなく、できる部分から、少しずつでもよいですので、より本質的なアクセシビリティ対応に取り組んでいただくのが、結果的には最も効率的な道筋であると考え、そのようにお伝えもしておりますので、お客様におかれましても、まずはしっかりとしたアクセシビリティに対する知識をお持ちになった上で、適切なご判断をされることを願っております。
バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2023年12月20日 14:03 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/431/ です。
]]>バーンワークス株式会社は2023年の12月をもって、設立から10周年の節目を迎えることになりました。
2013年12月に「ユーザーにとってより使いやすく、よりアクセスしやすいウェブサイトの構築」を、ウェブサイトのユーザー体験を重要視するクライアント様のために提供することを目標として創業した弊社ですが、多くのクライアント様はじめ、関係者の皆様に支えられ、おかげさまで10周年という、大きな節目を迎えることができましたこと、心より感謝申し上げます。
今後とも創業時の理念を忘れず、提供サービスの質の向上に努めてまいりたいと思いますので、引き続きよろしくお願いいたします。
]]>バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2023年12月 6日 07:55 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/429/ です。
]]>なお、2024年1月9日(火)より通常営業を再開いたします。休業中に頂いたお問い合わせ等に関しては営業再開後、順次対応させて頂きます。
]]>バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2023年11月30日 16:24 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/430/ です。
]]>なお、2023年1月10日(火)より通常営業を再開いたします。休業中に頂いたお問い合わせ等に関しては営業再開後、順次対応させて頂きます。
]]>バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2022年12月12日 09:28 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/419/ です。
]]>「できるポケット Web制作必携 HTML&CSS全事典 改訂3版」は、ポケットサイズ (B6判) の HTML/CSS のリファレンス本で、序盤にHTML/CSSの基礎知識編、本編は前半がHTMLリファレンス、後半がCSSリファレンスの構成となっています。全編にわたり、弊社加藤が執筆を行っております。
Webサイト制作の現場でHTML/CSSを利用されるWebクリエイターの皆様が、手元に1冊置いておくリファレンス本としては最適な内容となっております。ぜひお買い求め頂ければ幸いです。
現在、各書店にて予約注文を受付中です。オンラインショップでは、下記よりご予約・ご購入が可能です。
]]>バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2022年8月12日 10:09 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/418/ です。
]]>弊社がいただくウェブアクセシビリティ対応に関するご相談も、その件数は年々大幅に増加しており、ありがたく感じると共に、ウェブアクセシビリティ対応が当たり前の要件となってきたことは喜ばしいことと考えています。
一方で、ひとくちに「ウェブアクセシビリティ対応」といっても、その前提としての「ウェブアクセシビリティに関する要件」について明確に定まっていないと、その対応に必要な予算や工数、事前の準備などにかかる時間や手間などには大きな「振れ幅」ができてしまいます。場合によっては予算や時間が足りなくなってしまったり、計画を再考しなければならないという事態に陥ることもあるでしょう。
そこでこのコラムでは、ウェブアクセシビリティ対応における「要件」を考える際に知っておきたい用語の定義と、押さえておきたいポイントについて簡単に解説しようと思います。
弊社にウェブアクセシビリティ対応のご相談をいただくお客様を大きく分類すると、下記の2つに分けられます。
さらに上記のどちらのお立場かにかかわらず、下記のシチュエーションに分類できるかと思います。
前者の「ウェブアクセシビリティ要件が明確な」お客様に関しては、弊社にご相談いただく場合でも、その要件を示していただければ、それに応じて即座にお見積もりやご提案が可能ですが、後者の方々に関してはまずウェブアクセシビリティ要件を明確にするところからはじめなければなりません。
本コラムは、この「ウェブアクセシビリティ対応はしたいが、要件はまだ明確になっていない」という方々を対象に、その要件を定める上で何を理解しなければならないのか、さらにその要件によって対応にかかるコスト、時間、手間などに関してどのような差が出てくるのかをご理解頂ける内容を目指して執筆しています。
まずウェブアクセシビリティに関する最も基本的な部分として、
について順に説明していこうと思います。これら用語を正しく理解して頂くことで、確実で無理のないウェブアクセシビリティ要件を定めることができるでしょう。
本コラムの内容は特にことわりのない限り、原則として日本国内に拠点を置く企業や団体、かつ日本語を主に使用している方々を対象に、最も一般的と考えられる内容として執筆しております。海外に拠点を置く企業や団体、海外に向けてのみ発信されるウェブサイトなど、その特性によってはマッチしない場合もありますので、あらかじめご了承ください。
現時点において一般的に使用される、アクセシビリティのガイドラインとしては、下記のガイドラインが挙げられます。
このうち、「JIS X 8341-3:2016 (正式名称:高齢者・障害者等配慮設計指針-情報通信における機器,ソフトウェア及びサービス-第3部:ウェブコンテンツ)」と「WCAG 2.0 (国際規格「ISO/IEC 40500:2012」とも一致)」に関しては一致規格、つまり同一の規格として扱われるため、国内の企業、組織においては、「JIS X 8341-3:2016」を用いて、グローバルサイト(例えば他言語化されたウェブサイト)も含めたウェブアクセシビリティ対応が可能です。
一方で「WCAG 2.1」は 2018 年 6 月に W3C (World Wide Web Consortium) 勧告として発行された新しいガイドラインで、WCAG 2.0 を基に、WCAG 2.0 と後方互換性を持つ形で策定され、いくつかの新しい達成基準が追加されています。
現時点で「WCAG 2.1」には、日本語で記述された一致規格が存在しないため、このガイドラインを参照する場合は英語による理解が必要です。ウェブアクセシビリティ基盤委員会(WAIC)の翻訳ワーキンググループによる日本語訳が公開されていますが、正式なドキュメントとしては英語版となる点に注意してください。
どのガイドラインに基づいてウェブアクセシビリティ対応を行うかは自由ですが、一般的には「JIS X 8341-3:2016」を用いて行うことが多く、弊社でも特段の指定がない場合は、「JIS X 8341-3:2016」をガイドラインとして用いることを推奨しています。
ポイント
ウェブアクセシビリティ要件のひとつ、「対象とするアクセシビリティガイドライン」としては「JIS X 8341-3:2016」を用いることが一般的である。
「適合レベル」の話をする前に少しだけアクセシビリティガイドラインの構成について触れておきましょう。
前述した JIS X 8341-3:2016 や WCAG では、下記のような構成で文章がまとめられています。
JIS X 8341-3:2016 を例に挙げて説明すると、「原則」は下記の4つ。
原則の下には12の「ガイドライン」が設けられており、ウェブコンテンツをよりアクセシブルにするために制作者が取り組むべき基本的な目標を定めています。
そしてガイドラインの下に「達成基準」が設けられており、達成基準は試験によって検証可能な内容となっています。つまり、実際のウェブアクセシビリティ対応作業というのは、この達成基準を制作するウェブページが満たすようにしていく作業と言うことができるでしょう。
そして各達成基準には「適合レベル」というレベル分けがされており、「A」「AA」「AAA」という、3段階の適合レベルが定義されています。
JIS X 8341-3:2016 においては、
という形でそれぞれ分類されており、例えば「適合レベル AA」を目指す場合は、「A」および「AA」に分類される計 38 の達成基準のすべてをウェブページが満たす必要があるということになります。
ウェブアクセシビリティ対応において対象とするガイドラインが確定したら、次にこの適合レベルの中から、どのレベルを目指すのかを決める必要があります。
官公庁や自治体など、公的なウェブサイトに関しては総務省が定めるガイドライン 「みんなの公共サイト運用ガイドライン(2016年版)」 などによって「適合レベル AA」を目標とすることが定められている場合もありますが、一般的な企業や団体のウェブサイトの場合は任意で選択できます。
当然、目標とする適合レベルが「A」「AA」「AAA」と上がるごとに対応すべき項目も増えますし、試験を行う場合の工数、テストによって発見された問題点を修正するための手間、コストなども増えるため、とにかく目指すレベルが高ければよい、という単純な話ではありません。
まずは最低限のところからはじめたいという場合は「適合レベル A」からスタートしてみるのもよいでしょう。
これは余談ですが、ウェブアクセシビリティ対応は一度何か対応してそれで終わり、というものではありません。継続的にウェブコンテンツをアクセシブルに保つための取り組みが必要ですから、まずは無理のない範囲ではじめ、ウェブアクセシビリティへの取り組みを組織内の文化として当たり前にしていくことの方が重要です。
ポイント
ウェブコンテンツをアクセシブルに保つために満たすべき「達成基準」は「A」「AA」「AAA」という3段階のレベルに分かれており、これを「適合レベル」と呼ぶ。また、ウェブアクセシビリティ要件において、対象とするガイドラインが確定した後は、どの適合レベルを目標として取り組むかを定める必要がある。
前の章までで、「どのガイドラインを用いて」「どの適合レベルを目標にするか」までの要件は定まりました。次にこの要件を適用する「対応範囲」を決める必要があります。
対応範囲というのは、つまり対象となるウェブサイト全体(全ページ)なのか、それとも特定のディレクトリ以下のページのみなのか、あるいは特定のページのみなのか、ということです。
もし対象となるウェブサイトが全体でも 20 ページや 30 ページ程度の規模、かつすべてが HTML によるコンテンツだった場合、「ウェブサイト全体」を対応範囲としてもよいでしょう。しかし、もしウェブサイトが 1,000 ページや 10,000 ページといった規模で、かつ PDF 形式のファイルなど、HTML 以外のコンテンツも大量に含む場合、「ウェブサイト全体」を対応範囲としてしまうと、その工数は非常に大きなものとなります。
もちろん、それだけの工数と予算が確保できるのでやりましょう、ということであればそれは素晴らしいことですが、最初からあまりに対応範囲を広げすぎると、その規模によっては工数の算出自体が困難になってしまう場合があります。
そのような場合は、HTML 以外のコンテンツについては除外したり、特定のディレクトリ以下だけを対応範囲に含める、あるいは特定のディレクトリを対応範囲から除外する、といった方法で適切な範囲に絞ることも重要です。
ポイント
ウェブサイトのどの範囲をウェブアクセシビリティ対応の対象範囲とするのかを決めることも重要な要件のひとつである。
前の章までで、「どのガイドラインを用いて」「どの適合レベルを目標にするか」、そしてその「適用範囲」までが要件として定まりました。
最後に重要な要件として、目指すと決めた「適合レベル」に対して対象となるウェブページ群が「適合」していると試験によって確認できた後、それを「表明 (これを「適合表明」と言います)」するかどうかを定めなければなりません。
また、ガイドラインとして JIS X 8341-3:2016 を用いている場合は、「適合表明」を行うか、それとも情報通信アクセス協議会・ウェブアクセシビリティ基盤委員会が定める「対応度表記ガイドライン」に基づき「準拠」「一部準拠」「配慮」という用語を使用して、「対応度表記」をするのかを決める必要があります。
まずは各用語について簡単に理解していきましょう。
JIS X 8341-3:2016 や WCAG においては、そのガイドラインにおける適合レベルのひとつを、ウェブページが完全に満たしていることを表すため「適合」という用語が定義されています。
加えて「適合」はウェブページ全体、もしくはプロセス全体、例えば申込みフォームにおける「入力」「確認画面」「完了画面」といった一連の流れに関係するウェブページ群に対してのみ使用できると定義されています。
つまり、あるウェブページ内のすべてのコンテンツ(ウェブページ全体)が、「適合レベル A」に分類される達成基準をすべて満たすことが試験によって確認できた場合のみ、当該ウェブページが「適合レベル A」に対して「適合」したと言うことができるわけです。
ですから、もしあなたがウェブサイト制作者で、クライアントから『今回作成する申込フォームは JIS X 8341-3:2016 の「適合レベル A」に適合してください』と依頼された場合は、作成した申込フォームの一連のプロセスで表示されるウェブページ群すべてを試験し、JIS X 8341-3:2016 の「適合レベル A」に分類される達成基準をすべて満たしていることを確認すれば、クライアントの要望を満たせるということになります。
その上で、適合の要件を満たしたことを表明することを「適合表明」といいます。適合表明は任意ですので必ずしなければならないわけではありませんが、する場合はその要件もガイドライン内で定義されています。
例えば全 10 ページのウェブサイトがあり、全ページを試験した結果、すべて WCAG 2.0 の「適合レベル A」で求められる要件を満たしていることが確認できたとします。
この場合、「当該ウェブサイトの全ページは WCAG 2.0 の適合レベル A に適合した」という言い方で適合表明をすることができますし、仮に 10 ページのうち、8 ページだけが適合していたのであれば、適合が確認できたページの URL を羅列するような方法で適合表明をすることもできます。
つまり、適合表明の対象となるウェブページが特定できる状態であれば、ウェブサイト全体やウェブページ群に対してまとめて適合表明をすることができるわけです。
また、日本工業規格である JIS X 8341-3:2016 の場合は、
上記 2 つの規格に基づいて、「供給者適合宣言」を行うことにより、適合していることを示すこともできます (なお、JIS X 8341-3:2016 は JIS 法に定められる JIS マーク表示制度対象規格ではないため、JIS マークの表示はできません)。
しかし、これら「適合」や「適合表明」の要件は、大規模なウェブサイト全体、つまり「すべてのページ」に対して適合を報告したり、適合表明を行いたい場合においては大きな障壁があることに気がつくでしょう。
例えば、1,000 ページ、10,000 ページ規模のウェブサイト全体に対して適合表明をしようとすると、1,000 ページ、10,000 ページのすべてに対して試験を行い、「適合」という結果を全ページ分積み上げた上で適合表明をする必要が生じるということです。
もし、数百、数千ページを越えるような大規模ウェブサイトにおけるウェブアクセシビリティ要件として「ウェブサイト全体を対象に適合していることを納品報告書に記載せよ」ですとか、「ウェブサイト全体を対象に適合表明をせよ」などと定めてしまうと、納品される全ページに対して試験を実施しなければならなくなり、ほとんどの場合においてこれは工数的にも予算的にも現実的ではなくなってしまうでしょう。
前述したように「適合」および「適合表明」のみが唯一の方法である場合、ウェブサイトの規模や適合を目指す範囲によっては、そのために必要な試験の工数などの問題により、適合したことを表明すること自体が困難になってしまう場合が考えられます。
そこで、JIS X 8341-3:2016 に関しては、情報通信アクセス協議会・ウェブアクセシビリティ基盤委員会が独自に定めた「対応度表記ガイドライン」により、下記の用語を使用して、適合表明とは別の方法で適合の要件を満たしたことを表明できる道筋が設けられています。これが「対応度表記」です。
また、JIS X 8341-3:2016 においては、「附属書JB(参考)試験方法」において、適合試験の要件がまとめられていますが、この中では「ウェブページ一式単位」、つまり、よりわかりやすく言えば「ウェブサイト全体」をひとつの単位としての試験が認められていること、さらに対応度表記ガイドラインにおいても、この「ウェブページ一式単位」での試験結果をもって、ウェブサイト全体に対する対応度表記を行えることが示されている点がポイントです。
「ウェブページ一式単位」の試験では、下記のいずれかの方法で試験対象のページを選択して試験を実施することができます。
この中で、(a) 以外は所謂サンプリング試験になりますが、同、ウェブアクセシビリティ基盤委員会が公開している「試験実施ガイドライン」では、ウェブサイトの総ページ数が、
することで、適合要件を満たしているかを確認するのに十分な試験が可能という指標を示しています。
なお、100 ページ未満の場合は必ず (a) の全ページの試験が必須かというとそういうことではなく、試験にかかる工数やコストと相談しながら、(b) (c) (d) のいずれかを選択することも可能です。
ここまでを踏まえて、前述した「準拠」「一部準拠」「配慮」のそれぞれの用語を使用して対応度表記を行う場合の要件を、ウェブアクセシビリティ基盤委員会サイトから引用します。
表記 | ウェブアクセシビリティ方針の提示又は公開 | 目標とする適合レベルの達成基準の試験結果 | 追加で表記が必要な事項 |
---|---|---|---|
準拠 | 必須 | 試験を実施し、達成基準を全て満たしていることを確認した上で、試験結果を公開する | なし |
一部準拠 | 必須 | 試験を実施し、達成基準の一部を満たしていることを確認する。試験結果の公開は任意 | 今後の対応方針 部分適合を適用する場合は、その記述 |
配慮 | 必須 | 試験の実施の有無、結果は問わない | 目標とした適合レベル又は参照した達成基準一覧 |
出典: ウェブコンテンツの JIS X 8341-3:2016 対応度表記ガイドライン
例えば、制作するウェブサイト全体を「JIS X 8341-3:2016」の「適合レベル A」に「準拠」させたい場合は、対象となるウェブサイトから概ね 25 ページから 40 ページ程度を抽出して試験を行い、試験対象となったウェブページのすべてが適合要件を満たすことを確認 (当然、試験の実施によりもし問題が発見された場合は、ウェブサイト全体に対して同問題の修正を行い、再試験を実施する必要はあります) できた場合は、
という 2 つの要件を満たすことで、ウェブサイト全体に対して「JIS X 8341-3:2016 の適合レベル A に準拠した」という対応度表記を行うことが可能になるわけです。
この対応度表記は、クライアントへの納品報告などにおいても活用することが可能です。つまり、ウェブアクセシビリティ要件として「準拠」という用語を使用することで、大規模なウェブサイト全体を対応範囲とした場合でも、試験にかかる工数やコストが算出しやすく、現実的なウェブアクセシビリティ対応が可能です。
ポイント
JIS X 8341-3:2016 をガイドラインとして使用する場合、情報通信アクセス協議会・ウェブアクセシビリティ基盤委員会が定める対応度表記ガイドラインに基づき、「準拠」「一部準拠」「配慮」から適切な用語を選択して要件を定めるとよい。
さて、非常に長いコラムとなってしまいましたが、ウェブアクセシビリティ要件を明確にすることで、そこにかかる時間や手間、コストを正確に導き出せるようになるということがご理解頂けたのではないでしょうか。また、そのためにはいくつかの用語について理解が必要なこともおわかりいただけたかと思います。
もちろん、弊社にご相談いただければ、お客様のご要望、予算などに合わせて、このような要件の策定から実際のウェブアクセシビリティ対応プランの立案、試験の実施や実装技術的な支援までお手伝いさせて頂きますが、本コラムで書かせていただいた基本的なことを踏まえてご相談いただけると、よりお話がスムーズに進むと思いますので、是非ご参考まで。
]]> 参考リンクバーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2022年3月25日 13:19 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/416/ です。
]]>なお、2022年1月11日(火)より通常営業を再開いたします。休業中に頂いたお問い合わせ等に関しては営業再開後、順次対応させて頂きます。
]]>バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2021年12月 1日 11:16 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/414/ です。
]]>バーンワークス株式会社は、近年におけるウェブアクセシビリティに対する企業の関心の高まりと、その一方でウェブアクセシビリティに取り組むにあたって「誰に相談すればよいのかわからない」、「どのような取り組みを最初に行えばよいのか知りたい」といった企業、担当者様からいただくご質問、ご相談の声を鑑み、ウェブサイトのアクセシビリティチェック(試験)、レポート作成と、その結果を踏まえたオンラインコンサルティングを、お求めになりやすい低価格でワンセットにした、「ウェブアクセシビリティ対応スタートパック」の販売を開始いたします。
バーンワークスの「ウェブアクセシビリティ対応スタートパック」は、アクセシビリティチェックと簡易レポート、オンラインコンサルティングがセットになった、はじめてウェブアクセシビリティに取り組む企業に最適なパッケージです。
「ウェブアクセシビリティ対応スタートパック」について詳しくは下記の特設サイトをご覧ください。
ウェブアクセシビリティを確保することは、ウェブサイト構築における最も基本的な要件ともいえます。
しかし、ウェブアクセシビリティ対応に取り組むにあたって、どのようなことからはじめたらよいのか、わからないという企業の担当者様も多く、弊社にいただくウェブアクセシビリティ関連のご相談でも、具体的な要件がはっきりまとまった上でいただく内容より、「ウェブアクセシビリティ対応に取り組みたいが、どうすればよいか?」といった、何からはじめたらよいのか教えて欲しいという内容が多いのが現状です。
このような企業様に対して弊社では、簡単なアクセシビリティチェックの実施による現状把握や、その結果を踏まえたコンサルティングによって、まずはウェブアクセシビリティ対応の全体像や考え方をご理解頂くプロセスを経た上で、より本格的なウェブアクセシビリティへの取り組みに進んで頂くケースがほとんどです。
そこで、現状把握のための「アクセシビリティチェック」と、その結果をまとめた「レポートの作成」、およびその結果を踏まえて実施する「オンラインコンサルティング」という、ウェブアクセシビリティ対応のはじめの一歩として最適な内容をわかりやすい価格体系でパッケージ化することで、はじめてウェブアクセシビリティに取り組みたいという企業でも、導入しやすいスタートパックとして提供することとしました。
「ウェブアクセシビリティ対応スタートパック」は、下記の3つをひとつにまとめたサービスです。
JIS X 8341-3:2016、適合レベル AA を対象に、ウェブページが各達成基準を満たしているかをアクセシビリティ専門家による目視によってチェックします。
チェック結果をチェックシートにまとめると共に、チェック結果からわかる傾向と対策などをまとめた簡易レポートとあわせて納品物としてご提供します。
チェック結果、簡易レポートをベースに、オンラインによるコンサルティング、質疑応答など、フォローアップを実施します。
ウェブアクセシビリティ対応にはじめて取り組む企業に導入しやすく、わかりやすい価格体系を目指して、「ウェブアクセシビリティ対応スタートパック」では、低価格の「ミニマムプラン」と、標準的な「スタンダードプラン」の2つのプランをご用意しています。それぞれの内容、価格は下記の通りです。
まずはウェブサイト内の主要なページのアクセシビリティ対応状況を把握したい企業におすすめのミニマムなプラン。
販売価格: 98,000円(税別 / 税込み価格 107,800円)
ウェブサイト全体のアクセシビリティ対応状況を把握し、問題点を明確にしたい企業におすすめの標準的なプラン。
販売価格: 198,000円(税別 / 税込み価格 217,800円)
下記のような企業をはじめ、自社ウェブサイトのアクセシビリティに取り組みたいが、はじめに何をすればよいのかわからず困っている、どこか安心して相談できるパートナーが欲しい、という企業、団体、自治体の皆様を想定したサービスです。
「アクセシビリティ(accessibility)」とは、「アクセスのしやすさ」を意味します。ウェブサイトやアプリケーションだけでなく、あらゆる製品や建物、乗り物、サービスなどに対しての「利用しやすさ」、「支障なく利用できる度合い」を指す言葉として使用されます。
IT分野では「ウェブアクセシビリティ」という使われ方もしますが、この場合は「ウェブコンテンツ」、つまりウェブページやウェブアプリケーションによって提供される情報や機能に対するアクセスのしやすさを表します。ウェブコンテンツが特定の技術や利用者の能力に依存せず、さまざまな情報端末やソフトウェアから利用できることを目指し、「(ウェブ)アクセシビリティへの配慮」、「アクセシビリティを向上させる」といった言葉として使用されます。
アクセシビリティは特定の利用者、例えば障がい者の方などに向けて何か特別なことを行うものではなく、すべての利用者が、等しく利用可能な状態を目指していくことが基本的な概念です。利用者の年齢や能力、障がいの有無、あるいは利用環境によらず、すべての人が等しく情報にアクセスできるウェブが求められています。そして、それは企業ウェブサイトにおいても、利用者の利便性を向上させることで企業やブランドに対する信頼感を向上させ、情報に正しくアクセスできないことによって生じる機会損失を防ぐという意味で非常に重要です。
「ウェブアクセシビリティ対応スタートパック」、およびウェブアクセシビリティ対応に関して頂く質問とその答えを下記にまとめています。
JIS X 8341-3 および WCAG 2.0 を対象規格としたウェブアクセシビリティ対応案件において、中小企業から大手企業のウェブサイト、あるいは中央官庁、地方自治体をはじめとした公的機関のウェブサイトまで、多くの実績がございます。チェックやコンサルティングだけでなく、実装業務まで行っております。
チェック対象となるウェブページを1ページずつ、アクセシビリティチェックツールを使用して大まかにエラー内容を把握したり、それを基にアクセシビリティ専門家が実際に操作、ソースコードを確認するなどしながら JIS X 8341-3:2016、適合レベル 「A」および 「AA」の各達成基準に対して求められる基準を満たしているかを確認、チェックシートにまとめる作業です。
アクセシビリティチェックの結果をチェックシートの形で作成したものを、チェック対象ウェブページ、1ページに対して、1シート作成します。さらにチェック結果全体から、アクセシビリティ上の問題点の傾向や対策などを A4 サイズで1~2ページ程度にまとめた簡易レポートをあわせてチェック結果レポートと呼び、本サービスの納品物となります。
お申し込みいただいた時点での状況にもよりますが、概ね、ミニマムプランの場合は正式なご発注から5営業日程度でチェック作業は完了し、オンラインコンサルティングの実施が可能です。スタンダードプランの場合は、10営業日程度とお考えください。ご発注時に正式なスケジュールはお伝えします。
はい。英語版のウェブサイトであれば、日本語サイト同様にウェブアクセシビリティ関連サービスをご提供可能です。 英語以外の外国語で、コンテンツの文脈を正しく理解しないと正確な判断ができない達成基準などに関しては、対訳をいただくなどのサポートがないと対応が難しい場合もあります。
いいえ。本サービスに関しては、PC 版のブラウザソフトウェアで閲覧可能な一般的なウェブページを対象としています。また、SPA(Single Page Application)のような、同一 URL ながら操作に応じて画面の内容が大幅に変更されるウェブアプリケーションに関しても対象外となります。
いいえ。ウェブアクセシビリティガイドラインで定められている各達成基準と、具体的な実装方法を正しく理解した方でしたらどなたでも実施可能です。我々はすでに多くのウェブアクセシビリティチェックを行っている経験がありますので、より正確、かつスピーディなチェックがサービスとしてご提供できると考えております。
いいえ。ウェブアクセシビリティのチェックツールは様々なものがありますが、プログラムによる自動チェックのみで確認可能な項目は全体の半分にも満たないのが実際のところです。 例えば、画像に対する代替テキストがあるかないかはプログラムでチェック可能ですが、その代替テキストが文脈的に正しいものか、といった部分は、現状、プログラムだけで判断することは難しいでしょう。
]]>バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2021年6月22日 10:37 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/412/ です。
]]>2021年5月20日、Microsoft 社より IE11 のサポートを、2022年6月15日をもって終了することが発表されました ※1。弊社では、仕様検討、設計時の動作想定ブラウザ、および各テスト工程における動作確認対象ブラウザを、原則として、「メーカーによるサポート提供期間内にあるOS、およびブラウザ」と定めています。この原則に照らせば、IE11 はあと1年ほど、動作確認対象ブラウザに含まれることになります。
しかし、Webサイトの制作やWebアプリケーションの開発において、IE11での動作確認作業、および、個別の対応作業は生産性の低下を招く要因となっていることも事実であり、すでにサポートの終了が決定したブラウザに対応するためのリソースを、他の部分のクオリティ向上などに割り当てた方が建設的であるという理由から、このタイミングで IE11 を動作確認対象ブラウザから除外することを決定しました。
本発表以降、IE11 を動作確認対象ブラウザに含める場合は、別途 IE11 対応費用をお見積もりとなりますので、あらかじめご了承ください。
2021年6月1日以降に適用される、弊社受託案件における動作確認対象ブラウザに関しましてはこちらをご確認ください。
バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2021年6月 1日 10:54 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/410/ です。
]]>バーンワークス株式会社は、ウォンタ株式会社が提供する API ベースの日本製ヘッドレス CMS、「microCMS」のパートナー企業として登録されました。「microCMS」を活用した、Jamstack 構成によるハイパフォーマンスな Web サイトの構築に注力します。
microCMS は、利用ユーザーがサーバやデータベースのセットアップ、CMS のインストール作業や保守、メンテナンスを一切行わずに導入、運用が可能な SaaS(Software as a Service)形式の CMS(Content Management System / コンテンツ管理システム)です。
豊富なデータ入力形式のサポートと、それらを組み合わせて自由なコンテンツ管理画面の構築がスピーディ、かつ低コストで行え、入力されたデータを API 経由で取得することで柔軟なフロントエンド開発が可能になります。
microCMS の SaaS、つまりクラウドサービスとして提供される点、および API によるデータ取得に特化したヘッドレス CMS という特徴は、近年、サーバレスで高速な Web サイト構築手法として注目されている「Jamstack」との相性がよく、弊社でも近年、Jamstack による Web サイト構築の需要が高まっていることから、mictoCMS のパートナー企業として参加させていただくことで、microCMS を使用した開発に関するノウハウの蓄積をさらに推し進め、クライアントのニーズに対応可能な開発力の向上を図っていく所存です。
バーンワークスは Jamstack を積極的に採用することで、高パフォーマンス、高セキュリティ、ポータビリティに優れ、かつスケールしやすいウェブサイトの構築を実現。また、長年培った Web アクセシビリティの知見を活かし、ハイパフォーマンス、かつアクセシビリティに優れた Web サイトの構築を提供いたします。
Jamstack 構成での Web サイト構築、およびバーンワークスの Web アクセシビリティ対応サービスに関して詳しくは上記リンクをご覧ください。
]]>バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2021年5月10日 11:13 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/407/ です。
]]>「できるポケット HTML&CSS全事典」は、ポケットサイズ (B6判) の HTML/CSS のリファレンス本で、前半がHTMLリファレンス、後半がCSSリファレンスとなっています。全編にわたり、弊社加藤が執筆を行っております。なお、今回発売される第4刷での掲載内容変更はありません。
書籍の情報に関して詳しくは下記の特設ページをご確認ください。
ご購入は各書店にて。下記をはじめとした各オンラインショップでもご購入が可能です。
バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2021年4月 7日 09:26 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/405/ です。
]]>なお、本値引きサービスの終了時期については未定ですが、2021年内にご契約いただく案件に関しましては対象とさせて頂く予定です。
2021年5月20日、Microsoft 社より IE11 のサポートを、2022年6月15日をもって終了することが発表されました。これを受けまして、弊社では2021年6月1日以降にご契約頂く制作・開発案件に関しては、IE11 を動作確認対象ブラウザより除外いたします。それに伴い、本値引きサービスも同日をもって終了いたします。
弊社では、仕様検討、設計時の動作想定ブラウザ、および各テスト工程における動作確認対象ブラウザを、原則として、「メーカーによるサポート提供期間内にあるOS、およびブラウザ」と定めています ※1。
IE11は、Windows 8.1 において2023年1月10日まで、Windows 10 においては、最長で2029年1月9日までのサポートが予定されており、上記原則に照らせば、動作確認対象ブラウザに含まれます。
しかし一方で、Webサイトの制作やWebアプリケーションの開発において、IE11での動作確認作業、および、個別の対応作業は生産性の低下を招く要因となっており、その対応リソースを他の部分のクオリティ向上などに割り当てたいというのが正直な気持ちでした。
幸いなことに、2021年8月17日をもって、Microsoft社が、Microsoft 365 アプリ、およびサービスにおけるIE11のサポート終了を予定しており ※2、企業におけるIE11の利用に関しても、最新のEdgeブラウザやGoogle Chromeなどへの移行によって、徐々に減少していくことが見込まれます。
そこで、この機会にIE11での動作確認を省いてもよいとご判断いただけるお客様に対しては、感謝の気持ちを込めて、値引きという形で還元させていただきたく、本サービスの実施を決定いたしました。
いいえ。IE11を動作確認対象ブラウザから除外しても、実際にはほとんどの場合において、IE11による通常の閲覧に影響はありません。例えば一般的なWebサイトの場合であれば、一部の表示が多少崩れたり、他の最新ブラウザと画面上に表示されるデザインに差異が生じたり、主要でない機能が一部動作しないといったことが生じる可能性がございますが、これらはすべて、重要な情報の閲覧に大きな影響を与えない範囲で、と想定されます。
ご相談いただくWebサイトの要件、ユーザー層等に応じて、生じうる事象やその可能性、影響する範囲などについては弊社より説明させていただきますので、それをもってご判断いただくことが可能かと思います。
案件着手後の仕様変更に関しましては、原則として別途お見積もりとなるため、本値引きサービスをご利用後、やはりIE11への対応が必要となった場合に、値引き額のみの追加でIE11を動作確認対象ブラウザとできるかは、当該案件の規模、要件、あるいはお申し出のタイミング等によります。条件によってはご希望にそえない場合、あるいは値引き額を越える金額の追加費用が発生する場合もございますので、あらかじめご了承ください。
メーカーによるサポートが終了している古いブラウザ、例えば、IE10以前のInternet Explorerなどの利用は、セキュリティ上、大きなリスクとなり得ます。このようなリスクのある環境の利用が継続されることに貢献することは、弊社のポリシーに反しますことから、サポートが終了した旧ブラウザへの対応は、ご予算にかかわらず承りかねます。ご理解のほどお願いいたします。
※1 現在の弊社受託案件における動作確認対象ブラウザに関しましてはこちらをご確認ください。
※2 Microsoft 公式ブログ 「Microsoft 365 アプリの Internet Explorer 11 のサポート終了と Windows 10 での Microsoft Edge レガシー版のサービス終了」
]]>バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2021年1月19日 14:33 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/404/ です。
]]>2021年5月20日、Microsoft 社より IE11 のサポートを、2022年6月15日をもって終了することが発表されました。これを受けまして、弊社では2021年6月1日以降にご契約頂く制作・開発案件に関しては、IE11 を動作確認対象ブラウザより除外いたします。
Apple社製の各OSに関しては、原則として最新リリースから2バージョン前までを動作確認対象とさせて頂きます。
Android OSに関しては、原則として最新リリースから2バージョン前までを動作確認対象とさせて頂きます。
※ スマートフォン実機による動作確認につきましては、動作確認対象範囲の中で実機が確保できたもののみとさせていただき、すべての機種での動作確認を行うものではありません。
]]>バーンワークス株式会社では、Web サイトの新規構築やリニューアルをはじめ、Web サイトの改善や Web マーケティングに関するコンサルティングサービスを提供しています。詳しくは弊社サービス案内をご覧ください。
この記事は バーンワークス株式会社 が 2021年1月 8日 14:01 に公開しました。
オリジナル記事の URL は https://burnworks.com/news/article/402/ です。
]]>