ちゃふちゃふログ

ちゃふちゃふが日記を書いたり、勉強したことを備忘録的にまとめたりするブログです。

心当たりなくGoogleマイビジネスが公開停止になって復旧させるまでとGoogleへの不満

TL;DR

管理しているGoogleマイビジネス(地元の居酒屋さん)が事前の予告なく公開停止になって原因もわからなかった。最終的には新規アカウントを作ってオーナーの権限を移して再公開に至ったけど、推測される原因に納得がいかないしGoogleのサポートにも不満がある

詳細

2019年10月、管理しているGoogleマイビジネスが公開停止になってることに気づく。事前の予告はなく、気づいた段階でどのくらいの期間停止されていたかもわからない状態。知らぬ間にガイドライン違反をしていたか…?と思って登録情報を確認するも、問題になりそうな箇所は見つからず(そもそも登録されている情報を編集したのも覚えてないくらい以前の話だった)。素直にその旨をマイビジネスのサポートに問い合わせてみた。

ご登録状況を拝見いたしましたところ、大変畏れ入りますが、
< xxxx@example.com > のアカウント自体に問題があるようであり、
その結果、ビジネス情報が公開されない状況であるようでございます。

しかしながら、アカウント自体の問題につきましては、当窓口にて詳細を持ち合わせておりませんため、
明確な情報をお伝えさせていただく事ができかねます。

なお、ご返信をいただきましてもこれ以上の回答ができかねますこと
ご理解いただきますようお願い申し上げます。


これがサポートからの回答。どうやらマイビジネス上に問題があるのではなく、アカウント自体に問題があるとの回答。しかしアカウントを確認してみるも、やはり問題になりそうな箇所は見当たらない…。アカウントに関するサポート窓口もないようで、この段階でいったん手詰まり。Googleアカウントのコミュニティを見つけたので質問してみたが、解決に繋がりそうな回答は得られず。

次にGoogleマイビジネスのコミュニティで同様の状況と思われる質問を発見する。新規にアカウントを作りオーナーの権限を移行してみてはどうか、という提案があったので実行してみると、ひと月ほどでビジネスが公開されているのを確認。ビジネスが公開停止になっているという問題は解決したものの、原因がわからないしアカウントに問題があると言われている状況は変わらないので万が一にもBANされたらどうしようという一抹の不安は残ることに…。

おそらくこれが原因

年が明けて2020年1月、目にしたツイートで原因に思い当たる。

お前か~!!!!

何をしたかというと、SEO業界の有名人辻正浩さんによる【注意喚起】Google Maps最適化(MEO)業者への依頼は大きなリスクがありますという記事を読んでGoogleマップ上のガイドライン違反を片っ端から修正依頼したらどうもそれが引っかかったっぽい。

辻さんのブログは、Googleマップで店名に店名以外の情報(例えば「人気のお店です!」とか「飲み放題やってます!」とか)を入れるのはガイドライン違反だが実際には跋扈しているのを嘆き、情報の修正依頼は簡単にできるので積極的な通報を促す内容。一時期気分転換に片っ端からガイドライン違反の通報をしまくっていたので、たぶんこれが原因。修正依頼をして一時的に適正な状態になるも、すぐにガイドライン違反の状態に戻されてまた修正依頼を出すという、イタチごっこを繰り返していた店舗が複数あったのでそれが原因…?もしくは、修正依頼の件数が多すぎた(たぶん数百件は通報してる)のが原因じゃないかと推測。

頼むぜGoogleさんよ

ガイドライン違反の通報がアカウントに問題があるとされた原因である確証はないけど、引用したツイートを見るに間違いはないように思われる。マジでGoogleひどくない…?あと「これ以上の回答はできないよ!別の問い合わせ先の案内はしないけどね!」というのはユーザー体験として悪かったのでどうにかしてもらいたい。頼むぜGoogleさんよという気持ちです。

障害の区分とか障害のある人の割合とか調べてみた

なぜ調べようと思ったのか

Webのアクセシビリティの向上を目指す中で、障害そのものや統計上の情報などの知識が不足していると感じたので

障害のある人の定義

身体障害、知的障害、精神障害発達障害を含む。)その他の心身の機能の障害(以下「障害」と総称する。)がある者であつて、障害及び社会的障壁により継続的に日常生活又は社会生活に相当な制限を受ける状態にあるものをいう

障害者基本法:障害者施策 - 内閣府

日本における障害のある人の割合

2018年の厚労省による推計で7.4%。

障害ある人は936万人 人口の7.4% 厚労省推計:朝日新聞デジタル

日本における視覚障害のある人の人数と割合

厚労省の調査(平成28年生活のしづらさなどに関する調査(全国在宅障害児・者等実態調査)結果)によると推計31.2万人(2018年、人口の約0.24%)だが、日本眼科医会の調査(視覚障害がもたらす社会損失額、8.8兆円!!~視覚障害から生じる生産性やQOLの低下を、初めて試算~)によると約164万人(2007年、人口の約1.28%)。

なぜふたつの調査でこれだけの違いが出ているかというと、視覚障害者の定義がそれぞれで異なるため。厚労省の調査は身体障害者手帳の所持者数を算出しているが、眼科医会の調査はそれに限定しておらず、米国の基準を用いて推計しているため。

code.kzakza.com

日本における視覚障害のある人のロービジョンと全盲の割合

日本眼科医会の調査(視覚障害がもたらす社会損失額、8.8兆円!!~視覚障害から生じる生産性やQOLの低下を、初めて試算~)によるとロービジョンが約89%、全盲が約11%。

所感とか

  • 視覚障害に焦点を置いた調査になってしまった
  • 障害のある人の割合は少し驚いた。100人中7人というのは思っていたよりずっと多い
  • 視覚障害者数の推計は日本眼科医会の推計によったほうがいいように思う。少し前に知ったが、眼球使用困難症というものがあり、実質的には視覚障害の状態にあるものの視力自体には問題がないため視覚障害として認定されない問題があるらしい(いわゆる「福祉の谷間」)
  • 日本の視覚障害者は少なすぎる?…厳しい認定基準への疑問という話もある
  • 今まで割合を考えたことはなかったが、ロービジョンと全盲を比較するとロービジョンのほうがずっと多かった
  • こういった数字を頭に入れておくことは自身がアクセシビリティを考えるうえでも意義のあることだと思うし、例えばアクセシビリティの向上を社内やクライアントに訴える上でも有用だと思う。ちゃんと忘れないようにしよ…
  • よりよくまとまった資料がありそうなので知ってる人いたら教えて下さい(むしろこれを言いたいがためにこの記事を書いたまである)

登壇する際のよりアクセシブルなアンケートの取り方について

この記事はアクセシビリティ Advent Calendar 2019の12日目の記事でありギークハウス界隈 Advent Calendar 2019の19日目の記事でもあります。

connpass.com

先日こちらのイベントに参加してきました。

イベントで登壇者がアンケートを取るため、聴衆に挙手や拍手を求めるシーンはよくあると思いますが、このイベントでも聴衆に拍手を求めるシーンがありました。その時、アクセシビリティに関するイベントであり、障害を持っている方も多数来ていたというのもあると思うのですが、挙手ではなく拍手なのは視覚に障害のある方への配慮なのだな、なるほど、と一瞬納得しかけたのですが、直後にこのようなことに気づくわけです…

アンケートの結果を拍手で求めれば、視覚に障害があっても聴覚に頼ることができれば結果を聞くことができます。しかし、この場合には聴覚に障害がある方は結果にアクセスすることが難しくなります。僕は無意識的に視覚障害の方を前提に考えてしまい、拍手がよりよいアンケートの取り方だと納得しかけてしまったのですが(これはふだん僕が関心があるWebにおけるアクセシビリティがその性質上視覚障害の方を対象に考えることが多いからだと思われます)、聴覚障害のある方にとっては拍手がむしろアクセシブルでない手法となってしまうわけです。それでは、視覚障害の方と聴覚障害の方、どちらにもアクセシブルな手法はないかと考えると…

頭上での拍手をお願いするようにすれば、視覚に頼れる方は手が挙がっているのを見ることによって、聴覚に頼れる方は拍手の音量を聞くことによってアンケートの結果にアクセスすることができます。よりアクセシブルな手法と言えるのではないでしょうか。

というわけで、よりアクセシブルな手法として、登壇した際にアンケートを求める場合には「頭上での拍手」をお願いするのがよいのではないかと思います。ベストプラクティスに近いんじゃないかと思っているんですが、より良い案があれば教えてください…。

代替テキストをすべてひらがなにすることについて

この記事はWebアクセシビリティ Advent Calendar 2019の6日目の記事であると同時に、ギークハウス界隈 Advent Calendar 2019の6日目の記事でもあります。ギークハウス成分はありません。


先日Twitterで流れてきたツイートがこちら。


スクリーンリーダーで誤読されることを防ぐため、代替テキストをすべてひらがなにするという対応があるが、実際のユーザーの意見を聞いてみたい、というツイート。

個人的には、この配慮は不要だと思っているのですが…ひとつには、代替テキストはスクリーンリーダーのためだけに存在しているのではないということ。代替テキストは読み上げられるだけでなくテキストとして表示されることもあるので、その場合にすべてひらがなになっていると可読性が損なわれることになります。


もうひとつは、すべてひらがなにすると読み上げた際の抑揚がなくなるということ。


また、このような意見もあります。

この意見は非常に共感できます。


というように、代替テキストをすべてひらがなにするのは避けたほうがよい、というのが個人的な見解ではあるのですが…そもそも代替テキストをすべてひらがなにするという対応は視覚障害者の方から教えてもらったという話があり、あまり決めつけるべきではないというような気もしています。抑揚がなくなったとしても誤読がないほうがよいという意見も考えられますので、自分の対応としてはすべてひらがなにすることはしないにしても、そういった可能性は常に頭の片隅に置いておくようにしたいとは思います。当事者の方からの意見もありましたが、お一人の意見しか聞けてないですからね…。


また、すべてひらがなにするのは極端としても、スクリーンリーダーが誤読しないような配慮を求める意見もありました。




上記のツイートも含め関係すると思われたツイートをまとめたTogetterがあるので、よかったら見てみて下さい。

togetter.com


うおやま先生のヤンキー君と白杖ガールはこちら。

seiga.nicovideo.jp

aria-hidden="true"とrole="none presentation"の違いについて

今日もWAI-ARIAの話です。

timwright.org

そのまんまのタイトルの記事があったので以下引用。

Presentational roles are used when elements need to be in the DOM, but the semantics of them are inaccurate or unnecessary.

role="presentation"は要素がDOMとしては必要だけどセマンティクスが必要ないときに使われるとのこと。それに対し、

aria-hidden="true" means the element is removed from the tree

aria-hidden="true"は要素をアクセシビリティツリーから消すために使われる、つまり支援技術から認識されなくなるので、スクリーンリーダーで読み上げられなくなる。


簡単なデモはこちら。
ソースはこちら。


何も指定していないh1要素は「見出しレベル1 デフォルトの見出し」と読まれるが、aria-hidden="true"を指定したh1要素は読み上げられない。また、role="none presentation"を指定したh1要素は「role="none presentation"を設定した見出し」とだけ読まれ、h1要素としてのセマンティクスがなくなっているのがわかる(動作環境はWindows10,Chrome,NVDA)。

調べてたらspan要素にrole="presentation”を付与している例があったけど、spanにはそもそもセマンティクスがないので使用法としては不適切なはず。過去にはスペーサーやテーブルレイアウトで使われてたらしいけど、今はその使い方しないよね…。

また、role="none"については、WAI-ARIA 1.1の日本語訳から

ARIA 1.1において、ワーキンググループは、単語"presentation"または"presentational"の意図された意味の周囲の著者の混乱のために、presentationのロールに同義語としてnoneを導入した

実装がrole="none"に対して十分なサポートを含むまで、ウェブ制作者は、presentationロールだけでrole="presentation"またはnoneロールのフォールバックとして重複してrole="none presentation"を使用することを勧める

とのことなので、role="presentation"ではなくrole="none presentation"と指定してある。確かにpresentationって意味が取りにくいのでいい変更なんじゃないかなあと思う。ふたつ指定しなきゃいけないのは面倒だけど…。

momdo.github.io

role="none"を知れたのが今回の収穫ですね(今まで知らなかった)。

ARIA ライブリージョン完全に理解した

タイトルは詐欺です。

developer.mozilla.org

www.webprofessional.jp

ライブリージョンとは?

JSなどで動的にコンテンツを変化させた場合、視力によってコンテンツを確認しているユーザーには自明でも、スクリーンリーダーのユーザーなどにはコンテンツが変化したことがわからないことがある。ライブリージョンは動的なコンテンツの変化を支援技術を通じてユーザーに届ける技術。

実装方法

role属性statusもしくはalert(ライブリージョンロールと呼ばれる)を記述する。statusはスクリーンリーダーが読み上げ中のコンテンツを読み上げた後に変更されたコンテンツを読み上げる。alertは読み上げ中のコンテンツに割り込んで変更されたコンテンツを読み上げる。

また、aria-live属性というものもあり、しばしばライブリージョンロールと併用される。aria-live="polite"がstatusに相当し、aria-live="assertive"がalertに相当する。併用の理由としては「互換性を最大にする」、つまり動作する環境を増やすためっぽいけど、role="alert"とalia-live="assertive"の併用はiOSのVoiceOverで二重に読み上げられてしまうらしい。このあたりは実際に試すしかないかな。

<div role="status" aria-live="polite">この要素が変化したときにスクリーンリーダーで読み上げられる</div>

デモ

デモはこちらコードはこちら。スクリーンリーダーはNVDA、OSはWindows10、ブラウザはGoogle Chromeで確認。スクリーンリーダーを使用するとライブリージョンの記述がある場合はサイコロを振るたびに出目が読み上げられるが、ライブリージョンの記述がないと読み上げられない。視覚情報以外の手段でコンテンツを認識するユーザーにとってはこういう実装だと困るということ。

所感

ライブリージョンの初歩ぐらいはわかったかな、という感想。あとデモに関してサイコロを振るたびに出目が読み上げられると書いたけどこれは不正確で、なぜならば二度以上続けて同じ目が出た場合に読み上げられないから。ライブリージョンは変更されたコンテンツを支援技術を通じて知らせる技術。回避できそうな気もするけど、今後の宿題ということで。

GatsbyJS+Netlify+Netlify CMSでブログ構築

monologue.chuff-chuff.dev
完成したブログがこちら。


まずはNetlifyでホスティングするまで。参考にさせて頂いたサイトはこちら。
meuniere.hatenablog.jp

以下引っかかったところとその解決方法。

あとは特に詰まることなくデプロイまで。


次はNetlify CMSの導入。公式のドキュメントを参考にする。
www.netlifycms.org

上記ドキュメントに書いてあることにプラスして、GraphCMS から Netlify+Gatsby+Netlify CMS に移行して爆速になりましたも参考にしてGitHub - netlify/netlify-identity-widget: A zero config, framework free Netlify Identity widgetから以下のコードをstatic/admin/index.htmlに追加してログイン画面完成。

<!DOCTYPE html>
<html>
<head>
  <title>A static website</title>

  <!-- include the widget -->
  <script type="text/javascript" src="https://identity.netlify.com/v1/netlify-identity-widget.js"></script>
</head>
<body>
  <!-- Add a menu:
   Log in / Sign up - when the user is not logged in
   Username / Log out - when the user is logged in
  -->
  <div data-netlify-identity-menu></div>

  <!-- Add a simpler button:
    Simple button that will open the modal.
  -->
  <div data-netlify-identity-button>Login with Netlify Identity</div>
</body>
</html>


その他やったこと

これからやりたいこと

  • タグを使えるようにする
  • スタイルの修正
  • なぜかもともとあった記事が消せないので消せるように


GatsbyJSはReact製とのことで、カスタマイズできるようになるまでの学習コストが高そう。まあボチボチやりますかね…