【2人目確認中／調整待ち】[ リンクツールバー ] Edit linkを追加してaタグのアクセシビリティやSEOに対応しました

[mtdkei]

チケットへのリンク / 変更の理由（元のissueがあればリンクを貼り付ければOK）

#2199
#2134

どういう変更をしたか？

※ このプルリクはこちらでマージしますのでレビューだけでOKです。

リンクツールバーにEdit linkを追加し、aタグのrelやアクセシビリティ対応のテキストを設定できるようにしました。

• Add noreferrerと Add nofollow: relにnoreferrerとnofollowをそれぞれ設定できます。別タブで開く設定にした時は自動でnoreferrerにチェックが入ります。外すことも可能です。
• Accesibility link description: アクセシビリティ対応のテキスト設定にテキストを入れると、aria-labelとvisually-hiddenの要素を持つspanにテキストが入ります。デフォルトでは 「ブロック名 ＋ link」のテキストが設定されます。

対象ブロック

• Outer
• スライダー
• グリッドカラム
• グループ
• カバー
• カラム

スクリーンショットまたは動画

変更前 Before

変更後 After

実装者の確認事項

実装者はレビュワーに回す前に以下の事を確認してチェックをつけてください。

• 複数の意図の変更 （ 機能の不具合修正 + 別の機能追加など ） を含んでいないか？
• Files changed (変更ファイル)の内容は目視で確認したか？
• readme.txt に変更内容は書いたか？
• 本当にちゃんと確認をしたか？

プログラムの変更の場合

テストを書かないのは普通ではありません。書けるテストは極力書くようにしてください。

• 書けそうなテストは書いたか？

変更内容について何を確認したか、どういう方法で確認をしたかなど

新規、既存のOuterブロックともに以下を確認しました。

• 編集画面でリンクツールバーのEdit linkからAdd noreferrer、Add nofollow、Accesibility link descriptionが追加できることを確認しました。
• 編集画面で設定した relに noreferrer、nofollow、aria-labelとvisually-hiddenの要素を持つspanにAccesibility link descriptionに入力した内容がフロントエンドのソースで出力されていることを確認しました。
• 編集画面でEdit linkを設定後、設定を削除したときに、relの noreferrer、nofollow、が消えていることを確認しました。また、aria-labelとvisually-hiddenの要素を持つspanに 「ブロック名 ＋ link」のテキストが設定されます。
• リンクだけ設定した場合はaria-labelとvisually-hiddenの要素を持つspanに 「ブロック名 ＋ link」のテキストが設定されることを確認しました。

レビュワーに回す前の確認事項

• 実装者はこのテンプレートのチェック項目をちゃんと確認してチェックしたか？

レビュワー確認方法・確認内容など

実装者と同じ確認をしてください。
開発の方はコードの確認もお願いいたします。

---

レビュワー向け

レビュワーが確認して変更が反映されていない場合の確認事項

レビューしてみて意図した動作をしない場合は再度ビルドするなど以下の項目を確認してください。

• プルしたか？
• ビルドしたか？
• ビルドしたディレクトリは正しいか（別の開発環境のディレクトリを見ていないか）？
• npm install したか？
• composer install したか？
• キャッシュをクリアして確認したか？

[sysbird]

Outer の確認しました
ここユーザーがコントロールできるの便利ですね

これから順に対応されていくと思うので、マージ先をなにか中間のブランチ(A)にしておいて、最終的に(A) を developにマージするようにするとよいかも？ といっても私は詳しくないので、なにか考えがあったらおそれいりまする

[mtdkei]

ご確認、また、アドバイスをありがとうございます！

これから順に対応されていくと思うので、マージ先をなにか中間のブランチ(A)にしておいて、最終的に(A) を developにマージするようにするとよいかも？ といっても私は詳しくないので、なにか考えがあったらおそれいりまする

自分もどうしようか迷っていたのでとても参考になりました。
このブランチを中間のブランチにしてみようと思います。

[mthaichi]

これから順に対応されていくと思うので、マージ先をなにか中間のブランチ(A)にしておいて、最終的に(A) を developにマージするようにするとよいかも？ といっても私は詳しくないので、なにか考えがあったらおそれいりまする

自分もどうしようか迷っていたのでとても参考になりました。 このブランチを中間のブランチにしてみようと思います。

@sysbird @mtdkei 話の腰を折るようで申し訳ございませんが、ここは原則 develop にマージすることに対して、皆さんレビューすると思うので、それは曲げないほうが良いと思います。
中間ブランチも時間が経てば、developとの差分ができてしまいますし、できたものから順次developにマージしていったら良いと思いますが、いかがでしょうか。

[sysbird]

@mthaichi
いえいえ、ありがとうございます
このブランチは Outer のみ対応で、リンクツールバー を使っている他のブロックでリカバリーエラーが出ている状態ですので、うっかり develop にマージしてはいけない気がしました
あるいはこのブランチのなかで、他のブロックもまとめて対応していただくとよいでしょうかね

[mthaichi]

@sysbird @mtdkei ありがとうございます。そうですね。もちろんこのブランチをマージしてきちっと動くことが大前提です。

おそらく、共通で利用するコンポーネントを修正するので困っている感じですよね。
まず、コンポーネントを修正するのであれば、元々の呼び出し方でも新しい呼び出し方でも対応できるようにコンポーネントの修正をチャレンジしてみてください。渡されたpropsの値に応じて出力するHTMLを変えれば良いと思います。

それが難しければ、別コンポーネントを用意して、旧コンポーネントから新コンポーネントへ切り替えていくのもありですが、まずは同じコンポーネントで新旧どちらの呼び出し方でも対応でき、リカバリーも発生しないというのが、あるべき姿かなと思います。

難しいことがあれば、遠慮なくお尋ねください！

[mtdkei]

@mthaichi @sysbird
ご確認ありがとうございます！

今回のリンクツールバーの「Edit link」設定は、このプルリクエストで新しく追加したものになります。そのため、まだ「Edit link」に対応していないブロックがある状態でdevelopに反映されてしまうと、設定したリンクがフロントエンドで反映されない可能性があるのではと思い、少し慎重になっていました。

このブランチでは、まずOuterブロックのみ対応させているので、ご確認いただけましたら、次にスライダーブロックの対応も進めていこうと思っています！

[mthaichi]

@mthaichi @sysbird ご確認ありがとうございます！

今回のリンクツールバーの「Edit link」設定は、このプルリクエストで新しく追加したものになります。そのため、まだ「Edit link」に対応していないブロックがある状態でdevelopに反映されてしまうと、設定したリンクがフロントエンドで反映されない可能性があるのではと思い、少し慎重になっていました。

このブランチでは、まずOuterブロックのみ対応させているので、ご確認いただけましたら、次にスライダーブロックの対応も進めていこうと思っています！

@mtdkei 私の認識が違っていたら申し訳ないのですが、今はOuterしか対応していないのであれば、このブランチをこのままマージしたら、他のブロックでエラーが出る状況ではないでしょうか。
私が申し上げたのは、このブランチをdevelopにマージさせても、他のブロックは動くようにしてくださいという意味です。

全ブロックをこのブランチで一気に対応させるので、ここまでの実装を確認してほしいという趣旨であれば、Draftに切り替えて頂ければと思います。

[mtdkei]

@mthaichi
ご確認をありがとうございます。
おっしゃる通り、developにマージしてもリカバリーエラーが発生しないようにすることが重要だと理解しているつもりでした。そのため、全てのブロックに対応してから最終的にdevelopにマージする予定でした。
アドバイスいただいた通り、その場合はDraftが適していると思いましたので、まずはOuterブロックの確認をお願いできればと思います。次にスライダーブロックの対応を進めていきますので、引き続きよろしくお願いいたします。