すべてのプランで利用可能

公開前にチェックされる項目

読めない文字は、お客様を逃します。すべてのビルドは、公開前にコードで色のコントラストを確認し、公開後はデスクトップとスマートフォンの実際のページで確認します。読みにくい箇所があれば修正します。

焼きたてのパンを毎朝7時から。

測定中…

グラウンド

文章

お試しください:このデモはこのページ上でそのまま動きます。

しくみ

  1. コード内

    公開の前に、Briksは文字の色と背景色の組み合わせを確認します。

  2. 公開中のページで

    最初の公開後、デスクトップ幅とスマートフォン幅でページを確認します。

  3. 必要な場合の修復

    読みにくい文章は、一度だけ修正します。

ビルドのたびに確認される項目

コントラスト不足は、ウェブで最もよくあるアクセシビリティの問題の一つです。白地に薄いグレー、明るい写真に白、ブランドカラーに近い色のブランドカラーなどがその例です。Briks は公開の前に、サイトのコード上で色のコントラストを確認します。文字に使われた各色を、実際にその下にある背景と比べて測ります。

基準は、アクセシビリティガイドラインが定める WCAG AA です。本文は 4.5 対 1、大きな文字(24ピクセル以上、または太字で約19ピクセル以上)は 3 対 1 です。色が基準に届かない場合、その背景上の文字は読みやすい色にします。

最初の公開のあと、Briksは公開されたページをデスクトップとスマートフォンの幅で確認し、コントラストをもう一度チェックします。写真の上の文字など、ブラウザでしか分からない問題があるためです。読みにくい箇所があれば、1回だけ修正します。選んだすべてのページがメニューに入っているかも確認します。

アプリ向けの追加チェックと、公開時のチェック

アプリは公開前に、コードをもう一度確認します。特に被害が大きいミスを狙ったもので、ファイルに書き込まれた秘密鍵、上限のないデータベースへの書き込み、誰でも読めるメンバー用テーブル、文字列をつなげて作ったデータベースクエリが対象です。

サイトを本番環境に公開するとき、最初にローンチチェックが実行されます。事業にとって初日に恥ずかしい問題があると、公開を止めます。たとえば、残ったままのプレースホルダー文、置き換えや確認がされていない下書きの作り話、検索結果用の専用タイトルと説明がないページ、どこにもつながらないページ間リンク、存在しないアドレス用のページがない状態です。

最大12ページを読み込み、最大80件のリンクを試します。AIモデルは使わないため、クレジットはかかりません。

より詳しいチェックと、チェックされないこと

より詳しいチェックは、新規プロジェクトの手順にあるスイッチ1つで有効にでき、初期設定ではオフです。最初のバージョンが公開されると、Briksは4つの画面サイズで確認し、表示が崩れている部分、たとえば要素の重なりや、ある幅でレイアウトが崩れる問題を修正します。数分ほど長くかかり、クレジットも消費します。チェックの実行中は5クレジットが確保されます。以降の変更でも同じチェックを依頼できます。

限界をはっきりお伝えすると、重なり、画像、リンクのチェックはすべてのビルドで行われるわけではありません。通常の最初のビルドでは、コントラストのチェックとメニューのチェックが行われ、アプリの場合はコードの読み取りも行われます。リンクは、公開前チェック、またはオンにしたより詳しいチェックで確認されます。

これだけで目視の確認が不要になるわけではありません。本番環境に公開する前にスマートフォンでプレビューを開き、気になる点があれば普通の言葉で伝えてください。

公開前のチェックの活用例

3つの事業の例と、それぞれの使い方です。サイトの画像は、例として作った事業向けに Briks が作ったサンプルで、お客様のサイトではありません。

  1. キャンドル職人

    やわらかな写真に重ねる淡い色の文字

    キャンドル職人の女性が、霧のかかった海辺の写真の上に見出しを置きたいと考えています。スマートフォンの幅では、見出しの一部が空のいちばん明るい部分にかかってしまいます。ライブチェックはこうした不具合のためにあります。公開したページをパソコンとスマートフォンの両方で確認し、読みにくい文字を直します。

    Briksが例のキャンドル職人向けに作ったサンプルサイト、Saltmarsh Candlesのトップ部分
    Saltmarsh Candles は、キャンドル職人の例として Briks が作ったサンプルサイトで、実在のお客様ではありません。 サンプルを開く
  2. 法律事務所

    白地に明るいゴールドのブランドカラー

    ある法律事務所のブランドカラーは明るいゴールドです。白地の文字色にすると、4.5対1の基準を大きく下回ります。公開前にコードのチェックがこれを見つけ、その背景上の文字を読みやすい色にするので、事務所のページは最初の公開から読みやすいままです。

  3. 建設会社

    公開前にチェックされる、作業チーム向けの仕事用アプリ

    ある建設会社が、作業員が現場の仕事を記録する小さなアプリを依頼します。公開前に、ファイルに直接書かれたキーや、制限のない書き込みがないかコードが読み取られます。会社が本番環境に移そうとすると、公開前チェックで、作られていないProjectsページへのリンクも見つかり、修正されるまで公開は止まります。

得られるもの

  • 公開前にコード上でコントラストをWCAG AAの基準で確認
  • 公開中のページをデスクトップとスマートフォンで再度確認し、1件を修復しました
  • 選んだページはすべて、公開前にメニューに入ります
  • アプリは、ファイルに書き込まれたキー、制限のない書き込み、安全でないクエリがないかを確認されます

知っておくと便利なこと

  • 4つの幅でのより詳しいチェックは、新規プロジェクトの手順でスイッチ1つで有効にできます。
  • 本番環境に公開するときは、どこにもつながらないリンクの確認を含む公開前チェックが行われます。

公開前のチェックについての質問

ビルドのたびに何がチェックされますか?

コード上と、デスクトップおよびスマートフォンでの公開ページ上の色のコントラスト、そして選んだすべてのページがメニューに入っているかを確認します。

もっと詳しいチェックはありますか。

はい。4つの幅でのチェックをオンにでき、Publish to production を実行すると公開前チェックが走ります。

Briksはどの程度のコントラストを目指していますか?

WCAG AA:本文は4.5対1、大きな文字は3対1。

ビルドのたびにリンクと重なりをチェックしますか?

いいえ。リンクは本番環境への公開時のローンチチェックで、重なりは、オンにして使うより詳しいチェックで確認されます。

ご自身のビジネスで試してみましょう

一文で説明すれば、Briksが作ります。登録時に付与されるクレジットで、無料で始められます。