https://www.w3.org/WAI/GL/wiki/api.php?action=feedcontributions&feedformat=atom&user=DmacdonaWCAG WG - User contributions [en]2024-03-29T12:46:58ZUser contributionsMediaWiki 1.41.0https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.2_Implementation_Report&diff=11643WCAG 2.2 Implementation Report2021-09-13T18:09:33Z<p>Dmacdona: /* AAA Site Review */</p>
<hr />
<div>= Accessibility Guidelines Working Group WCAG 2.2 Implementation Report Work =<br />
<br />
== Resources ==<br />
* [https://www.w3.org/WAI/WCAG21/implementation-report/ WCAG 2.1 Implementation Report]<br />
<br />
== AAA Site Review ==<br />
<br />
Please add your name below the site you will be reviewing. <br />
<br />
[https://www.lflegal.com/ Lainey Feingold]<br />
* tester<br />
<br />
[https://www.funka.com/ Funka] <br />
*David MacDonald</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Scribe_List&diff=10576Scribe List2019-12-04T18:47:05Z<p>Dmacdona: /* 2019 Scribe History */</p>
<hr />
<div>To help ensure fairer scribe rotation, this list tracks scribes for the Web Content Accessibility Guidelines Working Group calls. The first available person at the top of the list should be the scribe. When someone scribes a call, increment the number of times they have scribed shown in brackets beside their name, then move them down to the lowest position in the list among people who have scribed the same number of times. <br />
<br />
== Scribe history ==<br />
<br />
List of meetings by date and who scribed: <br />
<br />
===2020 Scribe History===<br />
* 28 January: <br />
* 21 January: <br />
* 14 January: <br />
* 7 January:<br />
<br />
===2019 Scribe History===<br />
* 31 December: NO CALL<br />
* 24 December: NO CALL <br />
* 17 December: Laura, Jon<br />
* 10 December: Jake, Jennie<br />
* 3 December: Justine, Mike G<br />
* 26 November: Jennie, Chuck<br />
* 19 November: Rachael, Marc<br />
* 12 November: Katie, Detlev<br />
* 5 November: Jake, Laura<br />
* 29 October: Rachael, Wilco<br />
* 22 October: Chuck, Justine<br />
* 15 October: Bruce, Laura<br />
* 8 October: Jennie, Chuck<br />
* 1 October: Rachael, Laura<br />
* 24 September (CALL CANCELLED)<br />
* 19-20 September (TPAC): <br />
* 10 September: Mike Gower, Jennie<br />
* 3 September: Laura, Jon Avila<br />
* 27 August: Jake<br />
* 20 August: Justine, Detlev<br />
* 13 August: John Kirkwood, Jennie D<br />
* 6 August: Detlev, Chuck<br />
* 30 July: Jon, Marc<br />
* 23 July: Glenda, Chuck<br />
* 16 July: Laura, Rachael<br />
* 9 July: Jennie, Rachael<br />
* 2 July: No Meeting<br />
* 25 June: Jake Abma, Rachael<br />
* 18 June: Bruce Bailey, Mike Gower<br />
* 11 June: Bruce, Detlev<br />
* 4 June: Laura Carlson, David MacDonald<br />
* 28 May: Jake Abma, The Chuck<br />
* 21 May: Jon Avila, Rachael<br />
* 14 May: Detlev, Rachael<br />
* 7 May: Justine Pascal, Mike Gower<br />
* 30 Apr: Laura Carlson, Mike Elledge<br />
* 23 Apr: Brooks, David<br />
* 16 Apr: Chuck<br />
* 9 Apr: Marc, Rachael<br />
* 2 Apr: Jake Abma, JF<br />
* 26 Mar: Detlev, Chuck<br />
* 19 Mar: No meeting<br />
* 12 Mar (CSUN F2F): Rachael, Glenda, bruce_bailey, Mike_Elledge, jon_avila, Jake Abma<br />
* 11 Mar (CSUN F2F): Brooks, LuisG, (more)<br />
* 5 Mar: Tiffany, Rachael<br />
* 26 Feb: Laura, Mike Elledge<br />
* 19 Feb: Jake Abma, Brooks<br />
* 12 Feb: Rachael, Detlev<br />
* 5 Feb: Laura, Glenda<br />
* 29 Jan: Chuck, MichaelG<br />
* 22 Jan: Jake Abma, Chuck<br />
* 15 Jan: Brooks, Rachael<br />
* 8 Jan: Mike Elledge, Detlev<br />
<br />
===2018 Scribe History===<br />
* 18th Dec: Chuck, Rachael<br />
* 11th Dec: Jake Abma, Jon<br />
* 4th Dec: Laura, Jon<br />
* 27th Nov: Rachael, Alastair <br />
* 20th Nov: Detlev, Rachael<br />
* 13th Nov: Mike Elledge,<br />
* 16 Oct: Laura, Bruce<br />
* 9 Oct: Chuck, Mike Elledge<br />
* 2 Oct: Jake, Brooks<br />
* 25 Sept: Detlev, David MacDonald<br />
* 11 Sept: <br />
* 4 Sept: Jake, <br />
* 28 Aug: MikeE, DavidM<br />
* 21 Aug: Laura, Marc J.<br />
* 14 Aug: Brooks, Chuck<br />
* 7 Aug: Glenda, Chuck<br />
* 31 July: Mike Gower, Jemma<br />
* 24 July: Mike Elledge, Rachael<br />
* 17 July: Mike Elledge, Chuck<br />
* 10 July: Jim A, Mike Gower<br />
* 26 June: Chuck, Jake<br />
* 19 June: Detlev, Wilco<br />
* 12 June: Laura, Jim A<br />
* 5 June: Rachael, Mike Elledge, Glenda<br />
* 31 May: Mike Gower<br />
* 29 May: Detlev, Jon Avila<br />
* 24 May: Glenda<br />
* 22 May: Jake, Chuck<br />
* 17 May: Laura<br />
* 15 May: Marc, Jon Avila<br />
* 10 May: Brooks<br />
* 8 May: Mike Elledge, Laura<br />
* 3 May: Kathy, Kim<br />
* 1 May: Brooks, Mike Gower<br />
* 26 April: Chuck<br />
* 24 April: Laura, JimA<br />
* 19 April: AlastairC <br />
* 17 April: Mike Elledge<br />
* 12 April: AlastairC <br />
* 10 April: Brooks, Mike Gower<br />
* 5 April: Chuck<br />
* 3 April: Jake, Glenda<br />
* 29 March: Chuck<br />
* 27 March: Detlev<br />
* 6 March: Laura, David M<br />
* 27 Feb: JimA, Brooks<br />
* 22 Feb: [https://www.w3.org/WAI/GL/minutes-history.php No meeting]<br />
* 20 Feb: John Kirkwood, Laura<br />
* 15 Feb: Glenda<br />
* 13 Feb: Mike Elledge, Mike Gower<br />
* 8 Feb: No meeting<br />
* 6 Feb: Mike Elledge, Alastair<br />
* 1 Feb: John Foliot<br />
* 30 Jan: Mike_Elledge, JimA<br />
* 18 Jan: Brooks<br />
* 16 Jan: JimA, Mike Gower<br />
* 11 Jan: JF, JimA, Rachael<br />
* 10 Jan: Jim A, Mike Gower<br />
* 9 Jan: Laura, Detlev<br />
* 4 Jan: Jim A<br />
* 2 Jan: Jim A, AlastairC<br />
<br />
===2017 Scribe History===<br />
* 26 Dec: No call<br />
* 21 Dec: Laura, Brooks, Alastair, Mike Gower<br />
* 19 Dec: Glenda, James N<br />
* 14 Dec: Alastair, Detlev <br />
* 12 Dec: Mike Elledge, <br />
* 5 Dec: Laura, Jim Allan<br />
* 30 Nov: Mike Gower, Kathy, Jim A<br />
* 29 Nov: Rachael, Jim A, <br />
* 28 Nov: Alistair, JF, Jim A, Glenda<br />
* 27 Nov: Jim A, Detlev, Mike Gower, <br />
* 21 Nov: Bruce Bailey, Jake Abma<br />
* 20 Nov: Laura, Mike Gower<br />
* 17 Nov: Wilco/Mike Gower<br />
* 16 Nov: Jim A, Mike Gower<br />
* 15 Nov: Glenda<br />
* 14 Nov: Mike Elledge, Rachael<br />
* 13 Nov: Josh, Alastair<br />
* 7 Nov (TPAC): Rachael, TBD at TPAC <br />
* 6 Nov (TPAC): Rachael, TBD at TPAC<br />
* 2 Nov: Alastair Campbell<br />
* 31 Oct: Detlev, Laura<br />
* 26 Oct: Mike Gower<br />
* 24 Oct: Bruce Bailey<br />
* 19 Oct: Glenda S<br />
* 17 Oct: Jake Abma & Laura Carlson<br />
* 12 Oct: Jason White<br />
* 10 Oct: Mike Elledge & Jim A<br />
* 5 Oct: David MacDonald<br />
* 3 Oct: Bruce B/Mike Gower<br />
* 28 Sept: Brooks Newton <br />
* 26 Sept: Alistair Campbell<br />
* 21 Sept: Alex<br />
* 19 Sept: Glenda Sims<br />
* 12 Sept: David MacDonald<br />
* 5 Sept: Detlev<br />
* 29 Aug: John Kirkwood<br />
* 24 Aug: [https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0841.html No call Thursday 8/24]<br />
* 22 Aug: Mike Gower / Laura C<br />
* 17 Aug: Glenda Sims<br />
* 15 Aug: Detlev Fischer / Laura Carlson<br />
* 10 Aug: Alex Li / Laura Carlson<br />
* 8 Aug: Mike Elledge<br />
* 3 Aug: Kathy / Rachael<br />
* 1 Aug: Jim Allan<br />
* 25 July: Alastair Campbell<br />
* 20 July: Jan McSorley<br />
* 18 July: Chris Loiselle<br />
* 13 July: Chris Loiselle<br />
* 11 July: Jake Abma<br />
* 6 July: Jim Allan<br />
* 29 June: Alastair Campbell<br />
* 27 June: Chris Loiselle<br />
* 22 June: Rachael Bradley Montgomery and Mike Gower<br />
* 20 June: John Kirkwood<br />
* 15 June: Jeanne Spellman<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2017AprJun/1125.html 13 June meeting cancelled] (Mike Elledge had volunteered)<br />
* 8 June: Wilco Fiers<br />
* 6 June: Glenda Sims<br />
* 1 June: Detlev<br />
* 30 May: Detlev Fischer<br />
* 25 May: Laura Carlson<br />
* 23 May: Glenda Sims<br />
* 16 May: Mike Pluke<br />
* 11 May: John Foliot<br />
* 9 May: Chris Loiselle<br />
* 2 May: Chris Loiselle<br />
* 27 April: Chris Loiselle<br />
* 25 April: Mike Elledge<br />
* 18 April: Laura Carlson<br />
* 11 April: Kathy W<br />
* 4 April: James Nurthen<br />
* 28 March: Alastair Campbell<br />
* 21 March: Rachael Bradley Montgomery<br />
* 14 March: Lisa Seeman<br />
* 7 March: Moe Kraft<br />
* 28 February: CSUN - no call<br />
* 21 February: Wilco Fiers<br />
* 14 February: Shawn Lauriat<br />
* 7 February: Wayne Dick<br />
* 31 January: Jeanne Spellman<br />
* 24 January: Mike Gower<br />
* 17 January: Laura Carlson<br />
* 10 January: Alastair Campbell<br />
* 3 January: Mike Gower<br />
<br />
===2016 Scribe History===<br />
* 20 December: Rachael Bradley Montgomery<br />
* 13 December: Bruce Bailey<br />
* 6 December: David MacDonald<br />
* 29 November: Jeanne Spellman<br />
* 22 November: Chakravarthula, Srinivasu, Alastair Campbell<br />
* 15 November Mike Elledge<br />
* 8 November: Laura Carlson<br />
* 1 November: Rachael Bradley Montgomery<br />
* 25 October: Shawn Lauriat<br />
* 18 October: Rachael Bradley Montgomery/Marc Johlic<br />
* 11 October: Alistair C<br />
* 4 October: Wilco <br />
* 27 September: Laura Carlson<br />
* 12 September: Jeanne Spellman<br />
* 5 September: no call<br />
* 30 August: Marc Johlic<br />
* 23 August: Mike Elledge<br />
* 16 August: Alistair Campbell<br />
* 9 August: David MacDonald<br />
* 2 August: Wayne Dick<br />
* 26 July: Mike Elledge<br />
* 19 July: Rachael Bradley Montgomery<br />
* 12 July: Katie HS<br />
* 5 July: Laura Carlson <br />
* 28 June: Alistair<br />
* 21 June: Kathy Wahlbin <br />
* 14 June: Jeanne S<br />
* 7 June: Wayne Dick<br />
* 31 May: Shaun Lauriat<br />
* 24 May: Rachael Bradley Montgomery<br />
* 17 May: Mike Elledge<br />
* 10 May: Jon Avila<br />
* 3 May: Alistair Campbell <br />
* 26 April: Sarah Swierenga<br />
* 19 April: John Kirkwood<br />
* 12 April: David MacDonald<br />
* 5 April: Alastair Campbell<br />
* 29 March: Wayne Dick<br />
* 22 March: No meeting (CSUN)<br />
* 15 March: Jon Avila (Katie Haritos-Shea had volunteered)<br />
* 8 March: Laura Carlson<br />
* 1 March: Wayne Dick<br />
* 23 Feb: Mike Elledge <br />
* 16 Feb: Moe Kraft<br />
* 9 Feb: Adam Solomon<br />
* 2 Feb: [https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0118.html No meeting] (Katie Haritos-Shea had volunteered)<br />
* 26 Jan: Wayne Dick<br />
* 19 Jan: Laura Carlson<br />
* 12 Jan: Sarah Swierenga<br />
* 5 Jan: Mike Elledge<br />
<br />
=== 2015 Scribe History ===<br />
* 15 Dec: Wayne<br />
* 8 Dec: Laura Carlson<br />
* 1 Dec: Marc Johlic<br />
* 24 Nov: Wayne Dick<br />
* 17 Nov: Mike Elledge<br />
* 10 Nov: Jon Avila<br />
* 03 Nov: Laura Carlson<br />
* 13 Oct: Daniel Frank<br />
* 6 Oct: Katie Haritos-Shea<br />
* 22 Sept: David MacDonald<br />
* 15 Sept: Laura Carlson<br />
* 8 Sept: Bruce Bailey<br />
* 1 Sept: Laura Carlson<br />
* 25 August: Adam Solomon<br />
* 21 July: Moe Kraft<br />
* 23 June: Laura Carlson<br />
* 9 June: Laura Carlson<br />
* 2 June: Louis Cheng<br />
* 26 May: Mike Elledge<br />
* 19 May: David MacDonald <br />
* 12 May: Jon Avila <br />
* 5 May: Marc Johlic<br />
* 28 Apr: Katie Haritos-Shea <br />
* 21 Apr: Jon Avila<br />
* 14 Apr: Daniel Frank<br />
* 7 Apr: Loretta Guarino Reid<br />
* 31 Mar Katie Haritos-Shea<br />
* 24 Mar: Marc Johlic<br />
* 17 Mar: Kathy Wahlbin<br />
* 10 Mar: Mike Elledge<br />
* 17 Feb: Moe Kraft <br />
* 10 Feb: David MacDonald <br />
* 2 Feb: Loretta Guarino Reid<br />
* 27 Jan: David MacDonald<br />
* 20 Jan: Kathy Wahlbin<br />
* 13 Jan: Jon Avila<br />
* 6 Jan: Mike Elledge<br />
<br />
== Exempt ==<br />
<br />
The following people are not part of the scribe rotation for specific reasons: <br />
<br />
* Michael Cooper - drives meeting support tools<br />
* Andrew Kirkpatrick - chair<br />
* Joshue O'Connor - chair<br />
* Sailesh Pangchang<br />
* Kim Dirks<br />
<br />
== Related Info ==<br />
<br />
* [https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info Scribing Commands and Related Info]<br />
* [https://www.w3.org/WAI/GL/minutes-history.php Minutes Archive]</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Scribe_List&diff=10522Scribe List2019-10-29T16:14:04Z<p>Dmacdona: /* 2019 Scribe History */</p>
<hr />
<div>To help ensure fairer scribe rotation, this list tracks scribes for the Web Content Accessibility Guidelines Working Group calls. The first available person at the top of the list should be the scribe. When someone scribes a call, increment the number of times they have scribed shown in brackets beside their name, then move them down to the lowest position in the list among people who have scribed the same number of times. <br />
<br />
== Scribe history ==<br />
<br />
List of meetings by date and who scribed: <br />
<br />
===Canceled future meetings===<br />
* 24 December <br />
* 31 December<br />
<br />
===2019 Scribe History===<br />
* 31 December: NO CALL<br />
* 24 December: NO CALL <br />
* 17 December: David<br />
* 10 December: <br />
* 3 December: <br />
* 26 November: <br />
* 19 November: <br />
* 12 November: <br />
* 5 November: <br />
* 29 October: Rachael, Wilco<br />
* 22 October: Chuck, Justine<br />
* 15 October: Bruce, Laura<br />
* 8 October: Jennie, Chuck<br />
* 1 October: Rachael, Laura<br />
* 24 September (CALL CANCELLED)<br />
* 19-20 September (TPAC): <br />
* 10 September: Mike Gower, Jennie<br />
* 3 September: Laura, Jon Avila<br />
* 27 August: Jake<br />
* 20 August: Justine, Detlev<br />
* 13 August: John Kirkwood, Jennie D<br />
* 6 August: Detlev, Chuck<br />
* 30 July: Jon, Marc<br />
* 23 July: Glenda, Chuck<br />
* 16 July: Laura, Rachael<br />
* 9 July: Jennie, Rachael<br />
* 2 July: No Meeting<br />
* 25 June: Jake Abma, Rachael<br />
* 18 June: Bruce Bailey, Mike Gower<br />
* 11 June: Bruce, Detlev<br />
* 4 June: Laura Carlson, David MacDonald<br />
* 28 May: Jake Abma, The Chuck<br />
* 21 May: Jon Avila, Rachael<br />
* 14 May: Detlev, Rachael<br />
* 7 May: Justine Pascal, Mike Gower<br />
* 30 Apr: Laura Carlson, Mike Elledge<br />
* 23 Apr: Brooks, David<br />
* 16 Apr: Chuck<br />
* 9 Apr: Marc, Rachael<br />
* 2 Apr: Jake Abma, JF<br />
* 26 Mar: Detlev, Chuck<br />
* 19 Mar: No meeting<br />
* 12 Mar (CSUN F2F): Rachael, Glenda, bruce_bailey, Mike_Elledge, jon_avila, Jake Abma<br />
* 11 Mar (CSUN F2F): Brooks, LuisG, (more)<br />
* 5 Mar: Tiffany, Rachael<br />
* 26 Feb: Laura, Mike Elledge<br />
* 19 Feb: Jake Abma, Brooks<br />
* 12 Feb: Rachael, Detlev<br />
* 5 Feb: Laura, Glenda<br />
* 29 Jan: Chuck, MichaelG<br />
* 22 Jan: Jake Abma, Chuck<br />
* 15 Jan: Brooks, Rachael<br />
* 8 Jan: Mike Elledge, Detlev<br />
<br />
===2018 Scribe History===<br />
* 18th Dec: Chuck, Rachael<br />
* 11th Dec: Jake Abma, Jon<br />
* 4th Dec: Laura, Jon<br />
* 27th Nov: Rachael, Alastair <br />
* 20th Nov: Detlev, Rachael<br />
* 13th Nov: Mike Elledge,<br />
* 16 Oct: Laura, Bruce<br />
* 9 Oct: Chuck, Mike Elledge<br />
* 2 Oct: Jake, Brooks<br />
* 25 Sept: Detlev, David MacDonald<br />
* 11 Sept: <br />
* 4 Sept: Jake, <br />
* 28 Aug: MikeE, DavidM<br />
* 21 Aug: Laura, Marc J.<br />
* 14 Aug: Brooks, Chuck<br />
* 7 Aug: Glenda, Chuck<br />
* 31 July: Mike Gower, Jemma<br />
* 24 July: Mike Elledge, Rachael<br />
* 17 July: Mike Elledge, Chuck<br />
* 10 July: Jim A, Mike Gower<br />
* 26 June: Chuck, Jake<br />
* 19 June: Detlev, Wilco<br />
* 12 June: Laura, Jim A<br />
* 5 June: Rachael, Mike Elledge, Glenda<br />
* 31 May: Mike Gower<br />
* 29 May: Detlev, Jon Avila<br />
* 24 May: Glenda<br />
* 22 May: Jake, Chuck<br />
* 17 May: Laura<br />
* 15 May: Marc, Jon Avila<br />
* 10 May: Brooks<br />
* 8 May: Mike Elledge, Laura<br />
* 3 May: Kathy, Kim<br />
* 1 May: Brooks, Mike Gower<br />
* 26 April: Chuck<br />
* 24 April: Laura, JimA<br />
* 19 April: AlastairC <br />
* 17 April: Mike Elledge<br />
* 12 April: AlastairC <br />
* 10 April: Brooks, Mike Gower<br />
* 5 April: Chuck<br />
* 3 April: Jake, Glenda<br />
* 29 March: Chuck<br />
* 27 March: Detlev<br />
* 6 March: Laura, David M<br />
* 27 Feb: JimA, Brooks<br />
* 22 Feb: [https://www.w3.org/WAI/GL/minutes-history.php No meeting]<br />
* 20 Feb: John Kirkwood, Laura<br />
* 15 Feb: Glenda<br />
* 13 Feb: Mike Elledge, Mike Gower<br />
* 8 Feb: No meeting<br />
* 6 Feb: Mike Elledge, Alastair<br />
* 1 Feb: John Foliot<br />
* 30 Jan: Mike_Elledge, JimA<br />
* 18 Jan: Brooks<br />
* 16 Jan: JimA, Mike Gower<br />
* 11 Jan: JF, JimA, Rachael<br />
* 10 Jan: Jim A, Mike Gower<br />
* 9 Jan: Laura, Detlev<br />
* 4 Jan: Jim A<br />
* 2 Jan: Jim A, AlastairC<br />
<br />
===2017 Scribe History===<br />
* 26 Dec: No call<br />
* 21 Dec: Laura, Brooks, Alastair, Mike Gower<br />
* 19 Dec: Glenda, James N<br />
* 14 Dec: Alastair, Detlev <br />
* 12 Dec: Mike Elledge, <br />
* 5 Dec: Laura, Jim Allan<br />
* 30 Nov: Mike Gower, Kathy, Jim A<br />
* 29 Nov: Rachael, Jim A, <br />
* 28 Nov: Alistair, JF, Jim A, Glenda<br />
* 27 Nov: Jim A, Detlev, Mike Gower, <br />
* 21 Nov: Bruce Bailey, Jake Abma<br />
* 20 Nov: Laura, Mike Gower<br />
* 17 Nov: Wilco/Mike Gower<br />
* 16 Nov: Jim A, Mike Gower<br />
* 15 Nov: Glenda<br />
* 14 Nov: Mike Elledge, Rachael<br />
* 13 Nov: Josh, Alastair<br />
* 7 Nov (TPAC): Rachael, TBD at TPAC <br />
* 6 Nov (TPAC): Rachael, TBD at TPAC<br />
* 2 Nov: Alastair Campbell<br />
* 31 Oct: Detlev, Laura<br />
* 26 Oct: Mike Gower<br />
* 24 Oct: Bruce Bailey<br />
* 19 Oct: Glenda S<br />
* 17 Oct: Jake Abma & Laura Carlson<br />
* 12 Oct: Jason White<br />
* 10 Oct: Mike Elledge & Jim A<br />
* 5 Oct: David MacDonald<br />
* 3 Oct: Bruce B/Mike Gower<br />
* 28 Sept: Brooks Newton <br />
* 26 Sept: Alistair Campbell<br />
* 21 Sept: Alex<br />
* 19 Sept: Glenda Sims<br />
* 12 Sept: David MacDonald<br />
* 5 Sept: Detlev<br />
* 29 Aug: John Kirkwood<br />
* 24 Aug: [https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0841.html No call Thursday 8/24]<br />
* 22 Aug: Mike Gower / Laura C<br />
* 17 Aug: Glenda Sims<br />
* 15 Aug: Detlev Fischer / Laura Carlson<br />
* 10 Aug: Alex Li / Laura Carlson<br />
* 8 Aug: Mike Elledge<br />
* 3 Aug: Kathy / Rachael<br />
* 1 Aug: Jim Allan<br />
* 25 July: Alastair Campbell<br />
* 20 July: Jan McSorley<br />
* 18 July: Chris Loiselle<br />
* 13 July: Chris Loiselle<br />
* 11 July: Jake Abma<br />
* 6 July: Jim Allan<br />
* 29 June: Alastair Campbell<br />
* 27 June: Chris Loiselle<br />
* 22 June: Rachael Bradley Montgomery and Mike Gower<br />
* 20 June: John Kirkwood<br />
* 15 June: Jeanne Spellman<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2017AprJun/1125.html 13 June meeting cancelled] (Mike Elledge had volunteered)<br />
* 8 June: Wilco Fiers<br />
* 6 June: Glenda Sims<br />
* 1 June: Detlev<br />
* 30 May: Detlev Fischer<br />
* 25 May: Laura Carlson<br />
* 23 May: Glenda Sims<br />
* 16 May: Mike Pluke<br />
* 11 May: John Foliot<br />
* 9 May: Chris Loiselle<br />
* 2 May: Chris Loiselle<br />
* 27 April: Chris Loiselle<br />
* 25 April: Mike Elledge<br />
* 18 April: Laura Carlson<br />
* 11 April: Kathy W<br />
* 4 April: James Nurthen<br />
* 28 March: Alastair Campbell<br />
* 21 March: Rachael Bradley Montgomery<br />
* 14 March: Lisa Seeman<br />
* 7 March: Moe Kraft<br />
* 28 February: CSUN - no call<br />
* 21 February: Wilco Fiers<br />
* 14 February: Shawn Lauriat<br />
* 7 February: Wayne Dick<br />
* 31 January: Jeanne Spellman<br />
* 24 January: Mike Gower<br />
* 17 January: Laura Carlson<br />
* 10 January: Alastair Campbell<br />
* 3 January: Mike Gower<br />
<br />
===2016 Scribe History===<br />
* 20 December: Rachael Bradley Montgomery<br />
* 13 December: Bruce Bailey<br />
* 6 December: David MacDonald<br />
* 29 November: Jeanne Spellman<br />
* 22 November: Chakravarthula, Srinivasu, Alastair Campbell<br />
* 15 November Mike Elledge<br />
* 8 November: Laura Carlson<br />
* 1 November: Rachael Bradley Montgomery<br />
* 25 October: Shawn Lauriat<br />
* 18 October: Rachael Bradley Montgomery/Marc Johlic<br />
* 11 October: Alistair C<br />
* 4 October: Wilco <br />
* 27 September: Laura Carlson<br />
* 12 September: Jeanne Spellman<br />
* 5 September: no call<br />
* 30 August: Marc Johlic<br />
* 23 August: Mike Elledge<br />
* 16 August: Alistair Campbell<br />
* 9 August: David MacDonald<br />
* 2 August: Wayne Dick<br />
* 26 July: Mike Elledge<br />
* 19 July: Rachael Bradley Montgomery<br />
* 12 July: Katie HS<br />
* 5 July: Laura Carlson <br />
* 28 June: Alistair<br />
* 21 June: Kathy Wahlbin <br />
* 14 June: Jeanne S<br />
* 7 June: Wayne Dick<br />
* 31 May: Shaun Lauriat<br />
* 24 May: Rachael Bradley Montgomery<br />
* 17 May: Mike Elledge<br />
* 10 May: Jon Avila<br />
* 3 May: Alistair Campbell <br />
* 26 April: Sarah Swierenga<br />
* 19 April: John Kirkwood<br />
* 12 April: David MacDonald<br />
* 5 April: Alastair Campbell<br />
* 29 March: Wayne Dick<br />
* 22 March: No meeting (CSUN)<br />
* 15 March: Jon Avila (Katie Haritos-Shea had volunteered)<br />
* 8 March: Laura Carlson<br />
* 1 March: Wayne Dick<br />
* 23 Feb: Mike Elledge <br />
* 16 Feb: Moe Kraft<br />
* 9 Feb: Adam Solomon<br />
* 2 Feb: [https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0118.html No meeting] (Katie Haritos-Shea had volunteered)<br />
* 26 Jan: Wayne Dick<br />
* 19 Jan: Laura Carlson<br />
* 12 Jan: Sarah Swierenga<br />
* 5 Jan: Mike Elledge<br />
<br />
=== 2015 Scribe History ===<br />
* 15 Dec: Wayne<br />
* 8 Dec: Laura Carlson<br />
* 1 Dec: Marc Johlic<br />
* 24 Nov: Wayne Dick<br />
* 17 Nov: Mike Elledge<br />
* 10 Nov: Jon Avila<br />
* 03 Nov: Laura Carlson<br />
* 13 Oct: Daniel Frank<br />
* 6 Oct: Katie Haritos-Shea<br />
* 22 Sept: David MacDonald<br />
* 15 Sept: Laura Carlson<br />
* 8 Sept: Bruce Bailey<br />
* 1 Sept: Laura Carlson<br />
* 25 August: Adam Solomon<br />
* 21 July: Moe Kraft<br />
* 23 June: Laura Carlson<br />
* 9 June: Laura Carlson<br />
* 2 June: Louis Cheng<br />
* 26 May: Mike Elledge<br />
* 19 May: David MacDonald <br />
* 12 May: Jon Avila <br />
* 5 May: Marc Johlic<br />
* 28 Apr: Katie Haritos-Shea <br />
* 21 Apr: Jon Avila<br />
* 14 Apr: Daniel Frank<br />
* 7 Apr: Loretta Guarino Reid<br />
* 31 Mar Katie Haritos-Shea<br />
* 24 Mar: Marc Johlic<br />
* 17 Mar: Kathy Wahlbin<br />
* 10 Mar: Mike Elledge<br />
* 17 Feb: Moe Kraft <br />
* 10 Feb: David MacDonald <br />
* 2 Feb: Loretta Guarino Reid<br />
* 27 Jan: David MacDonald<br />
* 20 Jan: Kathy Wahlbin<br />
* 13 Jan: Jon Avila<br />
* 6 Jan: Mike Elledge<br />
<br />
== Exempt ==<br />
<br />
The following people are not part of the scribe rotation for specific reasons: <br />
<br />
* Michael Cooper - drives meeting support tools<br />
* Andrew Kirkpatrick - chair<br />
* Joshue O'Connor - chair<br />
* Sailesh Pangchang<br />
* Kim Dirks<br />
<br />
== Related Info ==<br />
<br />
* [https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info Scribing Commands and Related Info]<br />
* [https://www.w3.org/WAI/GL/minutes-history.php Minutes Archive]</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Scribe_List&diff=10192Scribe List2019-03-26T16:33:43Z<p>Dmacdona: /* 2019 Scribe History */</p>
<hr />
<div>To help ensure fairer scribe rotation, this list tracks scribes for the Web Content Accessibility Guidelines Working Group calls. The first available person at the top of the list should be the scribe. When someone scribes a call, increment the number of times they have scribed shown in brackets beside their name, then move them down to the lowest position in the list among people who have scribed the same number of times. <br />
<br />
== Scribe history ==<br />
<br />
List of meetings by date and who scribed: <br />
<br />
===2019 Scribe History===<br />
* 30 Apr: <br />
* 23 Apr: <br />
* 16 Apr: <br />
* 9 Apr: <br />
* 2 Apr: Jake Abma, David<br />
* 26 Mar: Detlev, Chuck<br />
* 19 Mar: No meeting<br />
* 12 Mar (CSUN F2F): Rachael, Glenda, bruce_bailey, Mike_Elledge, jon_avila<br />
* 11 Mar (CSUN F2F): Brooks, LuisG, (more)<br />
* 5 Mar: Tiffany, Rachael<br />
* 26 Feb: Laura, Mike Elledge<br />
* 19 Feb: Jake Abma, Brooks<br />
* 12 Feb: Rachael, Detlev<br />
* 5 Feb: Laura, Glenda<br />
* 29 Jan: Chuck, MichaelG<br />
* 22 Jan: Jake Abma, Chuck<br />
* 15 Jan: Brooks, Rachael<br />
* 8 Jan: Mike Elledge, Detlev<br />
<br />
===2018 Scribe History===<br />
* 18th Dec: Chuck, Rachael<br />
* 11th Dec: Jake Abma, Jon<br />
* 4th Dec: Laura, Jon<br />
* 27th Nov: Rachael, Alastair <br />
* 20th Nov: Detlev, Rachael<br />
* 13th Nov: Mike Elledge,<br />
* 16 Oct: Laura, Bruce<br />
* 9 Oct: Chuck, Mike Elledge<br />
* 2 Oct: Jake, Brooks<br />
* 25 Sept: Detlev, David MacDonald<br />
* 11 Sept: <br />
* 4 Sept: Jake, <br />
* 28 Aug: MikeE, DavidM<br />
* 21 Aug: Laura, Marc J.<br />
* 14 Aug: Brooks, Chuck<br />
* 7 Aug: Glenda, Chuck<br />
* 31 July: Mike Gower, Jemma<br />
* 24 July: Mike Elledge, Rachael<br />
* 17 July: Mike Elledge, Chuck<br />
* 10 July: Jim A, Mike Gower<br />
* 26 June: Chuck, Jake<br />
* 19 June: Detlev, Wilco<br />
* 12 June: Laura, Jim A<br />
* 5 June: Rachael, Mike Elledge, Glenda<br />
* 31 May: Mike Gower<br />
* 29 May: Detlev, Jon Avila<br />
* 24 May: Glenda<br />
* 22 May: Jake, Chuck<br />
* 17 May: Laura<br />
* 15 May: Marc, Jon Avila<br />
* 10 May: Brooks<br />
* 8 May: Mike Elledge, Laura<br />
* 3 May: Kathy, Kim<br />
* 1 May: Brooks, Mike Gower<br />
* 26 April: Chuck<br />
* 24 April: Laura, JimA<br />
* 19 April: AlastairC <br />
* 17 April: Mike Elledge<br />
* 12 April: AlastairC <br />
* 10 April: Brooks, Mike Gower<br />
* 5 April: Chuck<br />
* 3 April: Jake, Glenda<br />
* 29 March: Chuck<br />
* 27 March: Detlev<br />
* 6 March: Laura, David M<br />
* 27 Feb: JimA, Brooks<br />
* 22 Feb: [https://www.w3.org/WAI/GL/minutes-history.php No meeting]<br />
* 20 Feb: John Kirkwood, Laura<br />
* 15 Feb: Glenda<br />
* 13 Feb: Mike Elledge, Mike Gower<br />
* 8 Feb: No meeting<br />
* 6 Feb: Mike Elledge, Alastair<br />
* 1 Feb: John Foliot<br />
* 30 Jan: Mike_Elledge, JimA<br />
* 18 Jan: Brooks<br />
* 16 Jan: JimA, Mike Gower<br />
* 11 Jan: JF, JimA, Rachael<br />
* 10 Jan: Jim A, Mike Gower<br />
* 9 Jan: Laura, Detlev<br />
* 4 Jan: Jim A<br />
* 2 Jan: Jim A, AlastairC<br />
<br />
===2017 Scribe History===<br />
* 26 Dec: No call<br />
* 21 Dec: Laura, Brooks, Alastair, Mike Gower<br />
* 19 Dec: Glenda, James N<br />
* 14 Dec: Alastair, Detlev <br />
* 12 Dec: Mike Elledge, <br />
* 5 Dec: Laura, Jim Allan<br />
* 30 Nov: Mike Gower, Kathy, Jim A<br />
* 29 Nov: Rachael, Jim A, <br />
* 28 Nov: Alistair, JF, Jim A, Glenda<br />
* 27 Nov: Jim A, Detlev, Mike Gower, <br />
* 21 Nov: Bruce Bailey, Jake Abma<br />
* 20 Nov: Laura, Mike Gower<br />
* 17 Nov: Wilco/Mike Gower<br />
* 16 Nov: Jim A, Mike Gower<br />
* 15 Nov: Glenda<br />
* 14 Nov: Mike Elledge, Rachael<br />
* 13 Nov: Josh, Alastair<br />
* 7 Nov (TPAC): Rachael, TBD at TPAC <br />
* 6 Nov (TPAC): Rachael, TBD at TPAC<br />
* 2 Nov: Alastair Campbell<br />
* 31 Oct: Detlev, Laura<br />
* 26 Oct: Mike Gower<br />
* 24 Oct: Bruce Bailey<br />
* 19 Oct: Glenda S<br />
* 17 Oct: Jake Abma & Laura Carlson<br />
* 12 Oct: Jason White<br />
* 10 Oct: Mike Elledge & Jim A<br />
* 5 Oct: David MacDonald<br />
* 3 Oct: Bruce B/Mike Gower<br />
* 28 Sept: Brooks Newton <br />
* 26 Sept: Alistair Campbell<br />
* 21 Sept: Alex<br />
* 19 Sept: Glenda Sims<br />
* 12 Sept: David MacDonald<br />
* 5 Sept: Detlev<br />
* 29 Aug: John Kirkwood<br />
* 24 Aug: [https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0841.html No call Thursday 8/24]<br />
* 22 Aug: Mike Gower / Laura C<br />
* 17 Aug: Glenda Sims<br />
* 15 Aug: Detlev Fischer / Laura Carlson<br />
* 10 Aug: Alex Li / Laura Carlson<br />
* 8 Aug: Mike Elledge<br />
* 3 Aug: Kathy / Rachael<br />
* 1 Aug: Jim Allan<br />
* 25 July: Alastair Campbell<br />
* 20 July: Jan McSorley<br />
* 18 July: Chris Loiselle<br />
* 13 July: Chris Loiselle<br />
* 11 July: Jake Abma<br />
* 6 July: Jim Allan<br />
* 29 June: Alastair Campbell<br />
* 27 June: Chris Loiselle<br />
* 22 June: Rachael Bradley Montgomery and Mike Gower<br />
* 20 June: John Kirkwood<br />
* 15 June: Jeanne Spellman<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2017AprJun/1125.html 13 June meeting cancelled] (Mike Elledge had volunteered)<br />
* 8 June: Wilco Fiers<br />
* 6 June: Glenda Sims<br />
* 1 June: Detlev<br />
* 30 May: Detlev Fischer<br />
* 25 May: Laura Carlson<br />
* 23 May: Glenda Sims<br />
* 16 May: Mike Pluke<br />
* 11 May: John Foliot<br />
* 9 May: Chris Loiselle<br />
* 2 May: Chris Loiselle<br />
* 27 April: Chris Loiselle<br />
* 25 April: Mike Elledge<br />
* 18 April: Laura Carlson<br />
* 11 April: Kathy W<br />
* 4 April: James Nurthen<br />
* 28 March: Alastair Campbell<br />
* 21 March: Rachael Bradley Montgomery<br />
* 14 March: Lisa Seeman<br />
* 7 March: Moe Kraft<br />
* 28 February: CSUN - no call<br />
* 21 February: Wilco Fiers<br />
* 14 February: Shawn Lauriat<br />
* 7 February: Wayne Dick<br />
* 31 January: Jeanne Spellman<br />
* 24 January: Mike Gower<br />
* 17 January: Laura Carlson<br />
* 10 January: Alastair Campbell<br />
* 3 January: Mike Gower<br />
<br />
===2016 Scribe History===<br />
* 20 December: Rachael Bradley Montgomery<br />
* 13 December: Bruce Bailey<br />
* 6 December: David MacDonald<br />
* 29 November: Jeanne Spellman<br />
* 22 November: Chakravarthula, Srinivasu, Alastair Campbell<br />
* 15 November Mike Elledge<br />
* 8 November: Laura Carlson<br />
* 1 November: Rachael Bradley Montgomery<br />
* 25 October: Shawn Lauriat<br />
* 18 October: Rachael Bradley Montgomery/Marc Johlic<br />
* 11 October: Alistair C<br />
* 4 October: Wilco <br />
* 27 September: Laura Carlson<br />
* 12 September: Jeanne Spellman<br />
* 5 September: no call<br />
* 30 August: Marc Johlic<br />
* 23 August: Mike Elledge<br />
* 16 August: Alistair Campbell<br />
* 9 August: David MacDonald<br />
* 2 August: Wayne Dick<br />
* 26 July: Mike Elledge<br />
* 19 July: Rachael Bradley Montgomery<br />
* 12 July: Katie HS<br />
* 5 July: Laura Carlson <br />
* 28 June: Alistair<br />
* 21 June: Kathy Wahlbin <br />
* 14 June: Jeanne S<br />
* 7 June: Wayne Dick<br />
* 31 May: Shaun Lauriat<br />
* 24 May: Rachael Bradley Montgomery<br />
* 17 May: Mike Elledge<br />
* 10 May: Jon Avila<br />
* 3 May: Alistair Campbell <br />
* 26 April: Sarah Swierenga<br />
* 19 April: John Kirkwood<br />
* 12 April: David MacDonald<br />
* 5 April: Alastair Campbell<br />
* 29 March: Wayne Dick<br />
* 22 March: No meeting (CSUN)<br />
* 15 March: Jon Avila (Katie Haritos-Shea had volunteered)<br />
* 8 March: Laura Carlson<br />
* 1 March: Wayne Dick<br />
* 23 Feb: Mike Elledge <br />
* 16 Feb: Moe Kraft<br />
* 9 Feb: Adam Solomon<br />
* 2 Feb: [https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0118.html No meeting] (Katie Haritos-Shea had volunteered)<br />
* 26 Jan: Wayne Dick<br />
* 19 Jan: Laura Carlson<br />
* 12 Jan: Sarah Swierenga<br />
* 5 Jan: Mike Elledge<br />
<br />
=== 2015 Scribe History ===<br />
* 15 Dec: Wayne<br />
* 8 Dec: Laura Carlson<br />
* 1 Dec: Marc Johlic<br />
* 24 Nov: Wayne Dick<br />
* 17 Nov: Mike Elledge<br />
* 10 Nov: Jon Avila<br />
* 03 Nov: Laura Carlson<br />
* 13 Oct: Daniel Frank<br />
* 6 Oct: Katie Haritos-Shea<br />
* 22 Sept: David MacDonald<br />
* 15 Sept: Laura Carlson<br />
* 8 Sept: Bruce Bailey<br />
* 1 Sept: Laura Carlson<br />
* 25 August: Adam Solomon<br />
* 21 July: Moe Kraft<br />
* 23 June: Laura Carlson<br />
* 9 June: Laura Carlson<br />
* 2 June: Louis Cheng<br />
* 26 May: Mike Elledge<br />
* 19 May: David MacDonald <br />
* 12 May: Jon Avila <br />
* 5 May: Marc Johlic<br />
* 28 Apr: Katie Haritos-Shea <br />
* 21 Apr: Jon Avila<br />
* 14 Apr: Daniel Frank<br />
* 7 Apr: Loretta Guarino Reid<br />
* 31 Mar Katie Haritos-Shea<br />
* 24 Mar: Marc Johlic<br />
* 17 Mar: Kathy Wahlbin<br />
* 10 Mar: Mike Elledge<br />
* 17 Feb: Moe Kraft <br />
* 10 Feb: David MacDonald <br />
* 2 Feb: Loretta Guarino Reid<br />
* 27 Jan: David MacDonald<br />
* 20 Jan: Kathy Wahlbin<br />
* 13 Jan: Jon Avila<br />
* 6 Jan: Mike Elledge<br />
<br />
== Exempt ==<br />
<br />
The following people are not part of the scribe rotation for specific reasons: <br />
<br />
* Michael Cooper - drives meeting support tools<br />
* Andrew Kirkpatrick - chair<br />
* Joshue O'Connor - chair<br />
* Sailesh Pangchang<br />
* Kim Dirks<br />
<br />
== Related Info ==<br />
<br />
* [https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info Scribing Commands and Related Info]<br />
* [https://www.w3.org/WAI/GL/minutes-history.php Minutes Archive]</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Scribe_List&diff=10191Scribe List2019-03-26T16:33:06Z<p>Dmacdona: /* 2019 Scribe History */</p>
<hr />
<div>To help ensure fairer scribe rotation, this list tracks scribes for the Web Content Accessibility Guidelines Working Group calls. The first available person at the top of the list should be the scribe. When someone scribes a call, increment the number of times they have scribed shown in brackets beside their name, then move them down to the lowest position in the list among people who have scribed the same number of times. <br />
<br />
== Scribe history ==<br />
<br />
List of meetings by date and who scribed: <br />
<br />
===2019 Scribe History===<br />
* 30 Apr: <br />
* 23 Apr: <br />
* 16 Apr: <br />
* 9 Apr: David<br />
* 2 Apr: Jake Abma<br />
* 26 Mar: Detlev, Chuck<br />
* 19 Mar: No meeting<br />
* 12 Mar (CSUN F2F): Rachael, Glenda, bruce_bailey, Mike_Elledge, jon_avila<br />
* 11 Mar (CSUN F2F): Brooks, LuisG, (more)<br />
* 5 Mar: Tiffany, Rachael<br />
* 26 Feb: Laura, Mike Elledge<br />
* 19 Feb: Jake Abma, Brooks<br />
* 12 Feb: Rachael, Detlev<br />
* 5 Feb: Laura, Glenda<br />
* 29 Jan: Chuck, MichaelG<br />
* 22 Jan: Jake Abma, Chuck<br />
* 15 Jan: Brooks, Rachael<br />
* 8 Jan: Mike Elledge, Detlev<br />
<br />
===2018 Scribe History===<br />
* 18th Dec: Chuck, Rachael<br />
* 11th Dec: Jake Abma, Jon<br />
* 4th Dec: Laura, Jon<br />
* 27th Nov: Rachael, Alastair <br />
* 20th Nov: Detlev, Rachael<br />
* 13th Nov: Mike Elledge,<br />
* 16 Oct: Laura, Bruce<br />
* 9 Oct: Chuck, Mike Elledge<br />
* 2 Oct: Jake, Brooks<br />
* 25 Sept: Detlev, David MacDonald<br />
* 11 Sept: <br />
* 4 Sept: Jake, <br />
* 28 Aug: MikeE, DavidM<br />
* 21 Aug: Laura, Marc J.<br />
* 14 Aug: Brooks, Chuck<br />
* 7 Aug: Glenda, Chuck<br />
* 31 July: Mike Gower, Jemma<br />
* 24 July: Mike Elledge, Rachael<br />
* 17 July: Mike Elledge, Chuck<br />
* 10 July: Jim A, Mike Gower<br />
* 26 June: Chuck, Jake<br />
* 19 June: Detlev, Wilco<br />
* 12 June: Laura, Jim A<br />
* 5 June: Rachael, Mike Elledge, Glenda<br />
* 31 May: Mike Gower<br />
* 29 May: Detlev, Jon Avila<br />
* 24 May: Glenda<br />
* 22 May: Jake, Chuck<br />
* 17 May: Laura<br />
* 15 May: Marc, Jon Avila<br />
* 10 May: Brooks<br />
* 8 May: Mike Elledge, Laura<br />
* 3 May: Kathy, Kim<br />
* 1 May: Brooks, Mike Gower<br />
* 26 April: Chuck<br />
* 24 April: Laura, JimA<br />
* 19 April: AlastairC <br />
* 17 April: Mike Elledge<br />
* 12 April: AlastairC <br />
* 10 April: Brooks, Mike Gower<br />
* 5 April: Chuck<br />
* 3 April: Jake, Glenda<br />
* 29 March: Chuck<br />
* 27 March: Detlev<br />
* 6 March: Laura, David M<br />
* 27 Feb: JimA, Brooks<br />
* 22 Feb: [https://www.w3.org/WAI/GL/minutes-history.php No meeting]<br />
* 20 Feb: John Kirkwood, Laura<br />
* 15 Feb: Glenda<br />
* 13 Feb: Mike Elledge, Mike Gower<br />
* 8 Feb: No meeting<br />
* 6 Feb: Mike Elledge, Alastair<br />
* 1 Feb: John Foliot<br />
* 30 Jan: Mike_Elledge, JimA<br />
* 18 Jan: Brooks<br />
* 16 Jan: JimA, Mike Gower<br />
* 11 Jan: JF, JimA, Rachael<br />
* 10 Jan: Jim A, Mike Gower<br />
* 9 Jan: Laura, Detlev<br />
* 4 Jan: Jim A<br />
* 2 Jan: Jim A, AlastairC<br />
<br />
===2017 Scribe History===<br />
* 26 Dec: No call<br />
* 21 Dec: Laura, Brooks, Alastair, Mike Gower<br />
* 19 Dec: Glenda, James N<br />
* 14 Dec: Alastair, Detlev <br />
* 12 Dec: Mike Elledge, <br />
* 5 Dec: Laura, Jim Allan<br />
* 30 Nov: Mike Gower, Kathy, Jim A<br />
* 29 Nov: Rachael, Jim A, <br />
* 28 Nov: Alistair, JF, Jim A, Glenda<br />
* 27 Nov: Jim A, Detlev, Mike Gower, <br />
* 21 Nov: Bruce Bailey, Jake Abma<br />
* 20 Nov: Laura, Mike Gower<br />
* 17 Nov: Wilco/Mike Gower<br />
* 16 Nov: Jim A, Mike Gower<br />
* 15 Nov: Glenda<br />
* 14 Nov: Mike Elledge, Rachael<br />
* 13 Nov: Josh, Alastair<br />
* 7 Nov (TPAC): Rachael, TBD at TPAC <br />
* 6 Nov (TPAC): Rachael, TBD at TPAC<br />
* 2 Nov: Alastair Campbell<br />
* 31 Oct: Detlev, Laura<br />
* 26 Oct: Mike Gower<br />
* 24 Oct: Bruce Bailey<br />
* 19 Oct: Glenda S<br />
* 17 Oct: Jake Abma & Laura Carlson<br />
* 12 Oct: Jason White<br />
* 10 Oct: Mike Elledge & Jim A<br />
* 5 Oct: David MacDonald<br />
* 3 Oct: Bruce B/Mike Gower<br />
* 28 Sept: Brooks Newton <br />
* 26 Sept: Alistair Campbell<br />
* 21 Sept: Alex<br />
* 19 Sept: Glenda Sims<br />
* 12 Sept: David MacDonald<br />
* 5 Sept: Detlev<br />
* 29 Aug: John Kirkwood<br />
* 24 Aug: [https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JulSep/0841.html No call Thursday 8/24]<br />
* 22 Aug: Mike Gower / Laura C<br />
* 17 Aug: Glenda Sims<br />
* 15 Aug: Detlev Fischer / Laura Carlson<br />
* 10 Aug: Alex Li / Laura Carlson<br />
* 8 Aug: Mike Elledge<br />
* 3 Aug: Kathy / Rachael<br />
* 1 Aug: Jim Allan<br />
* 25 July: Alastair Campbell<br />
* 20 July: Jan McSorley<br />
* 18 July: Chris Loiselle<br />
* 13 July: Chris Loiselle<br />
* 11 July: Jake Abma<br />
* 6 July: Jim Allan<br />
* 29 June: Alastair Campbell<br />
* 27 June: Chris Loiselle<br />
* 22 June: Rachael Bradley Montgomery and Mike Gower<br />
* 20 June: John Kirkwood<br />
* 15 June: Jeanne Spellman<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2017AprJun/1125.html 13 June meeting cancelled] (Mike Elledge had volunteered)<br />
* 8 June: Wilco Fiers<br />
* 6 June: Glenda Sims<br />
* 1 June: Detlev<br />
* 30 May: Detlev Fischer<br />
* 25 May: Laura Carlson<br />
* 23 May: Glenda Sims<br />
* 16 May: Mike Pluke<br />
* 11 May: John Foliot<br />
* 9 May: Chris Loiselle<br />
* 2 May: Chris Loiselle<br />
* 27 April: Chris Loiselle<br />
* 25 April: Mike Elledge<br />
* 18 April: Laura Carlson<br />
* 11 April: Kathy W<br />
* 4 April: James Nurthen<br />
* 28 March: Alastair Campbell<br />
* 21 March: Rachael Bradley Montgomery<br />
* 14 March: Lisa Seeman<br />
* 7 March: Moe Kraft<br />
* 28 February: CSUN - no call<br />
* 21 February: Wilco Fiers<br />
* 14 February: Shawn Lauriat<br />
* 7 February: Wayne Dick<br />
* 31 January: Jeanne Spellman<br />
* 24 January: Mike Gower<br />
* 17 January: Laura Carlson<br />
* 10 January: Alastair Campbell<br />
* 3 January: Mike Gower<br />
<br />
===2016 Scribe History===<br />
* 20 December: Rachael Bradley Montgomery<br />
* 13 December: Bruce Bailey<br />
* 6 December: David MacDonald<br />
* 29 November: Jeanne Spellman<br />
* 22 November: Chakravarthula, Srinivasu, Alastair Campbell<br />
* 15 November Mike Elledge<br />
* 8 November: Laura Carlson<br />
* 1 November: Rachael Bradley Montgomery<br />
* 25 October: Shawn Lauriat<br />
* 18 October: Rachael Bradley Montgomery/Marc Johlic<br />
* 11 October: Alistair C<br />
* 4 October: Wilco <br />
* 27 September: Laura Carlson<br />
* 12 September: Jeanne Spellman<br />
* 5 September: no call<br />
* 30 August: Marc Johlic<br />
* 23 August: Mike Elledge<br />
* 16 August: Alistair Campbell<br />
* 9 August: David MacDonald<br />
* 2 August: Wayne Dick<br />
* 26 July: Mike Elledge<br />
* 19 July: Rachael Bradley Montgomery<br />
* 12 July: Katie HS<br />
* 5 July: Laura Carlson <br />
* 28 June: Alistair<br />
* 21 June: Kathy Wahlbin <br />
* 14 June: Jeanne S<br />
* 7 June: Wayne Dick<br />
* 31 May: Shaun Lauriat<br />
* 24 May: Rachael Bradley Montgomery<br />
* 17 May: Mike Elledge<br />
* 10 May: Jon Avila<br />
* 3 May: Alistair Campbell <br />
* 26 April: Sarah Swierenga<br />
* 19 April: John Kirkwood<br />
* 12 April: David MacDonald<br />
* 5 April: Alastair Campbell<br />
* 29 March: Wayne Dick<br />
* 22 March: No meeting (CSUN)<br />
* 15 March: Jon Avila (Katie Haritos-Shea had volunteered)<br />
* 8 March: Laura Carlson<br />
* 1 March: Wayne Dick<br />
* 23 Feb: Mike Elledge <br />
* 16 Feb: Moe Kraft<br />
* 9 Feb: Adam Solomon<br />
* 2 Feb: [https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0118.html No meeting] (Katie Haritos-Shea had volunteered)<br />
* 26 Jan: Wayne Dick<br />
* 19 Jan: Laura Carlson<br />
* 12 Jan: Sarah Swierenga<br />
* 5 Jan: Mike Elledge<br />
<br />
=== 2015 Scribe History ===<br />
* 15 Dec: Wayne<br />
* 8 Dec: Laura Carlson<br />
* 1 Dec: Marc Johlic<br />
* 24 Nov: Wayne Dick<br />
* 17 Nov: Mike Elledge<br />
* 10 Nov: Jon Avila<br />
* 03 Nov: Laura Carlson<br />
* 13 Oct: Daniel Frank<br />
* 6 Oct: Katie Haritos-Shea<br />
* 22 Sept: David MacDonald<br />
* 15 Sept: Laura Carlson<br />
* 8 Sept: Bruce Bailey<br />
* 1 Sept: Laura Carlson<br />
* 25 August: Adam Solomon<br />
* 21 July: Moe Kraft<br />
* 23 June: Laura Carlson<br />
* 9 June: Laura Carlson<br />
* 2 June: Louis Cheng<br />
* 26 May: Mike Elledge<br />
* 19 May: David MacDonald <br />
* 12 May: Jon Avila <br />
* 5 May: Marc Johlic<br />
* 28 Apr: Katie Haritos-Shea <br />
* 21 Apr: Jon Avila<br />
* 14 Apr: Daniel Frank<br />
* 7 Apr: Loretta Guarino Reid<br />
* 31 Mar Katie Haritos-Shea<br />
* 24 Mar: Marc Johlic<br />
* 17 Mar: Kathy Wahlbin<br />
* 10 Mar: Mike Elledge<br />
* 17 Feb: Moe Kraft <br />
* 10 Feb: David MacDonald <br />
* 2 Feb: Loretta Guarino Reid<br />
* 27 Jan: David MacDonald<br />
* 20 Jan: Kathy Wahlbin<br />
* 13 Jan: Jon Avila<br />
* 6 Jan: Mike Elledge<br />
<br />
== Exempt ==<br />
<br />
The following people are not part of the scribe rotation for specific reasons: <br />
<br />
* Michael Cooper - drives meeting support tools<br />
* Andrew Kirkpatrick - chair<br />
* Joshue O'Connor - chair<br />
* Sailesh Pangchang<br />
* Kim Dirks<br />
<br />
== Related Info ==<br />
<br />
* [https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info Scribing Commands and Related Info]<br />
* [https://www.w3.org/WAI/GL/minutes-history.php Minutes Archive]</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9947Wcag21-techniques2018-06-25T14:36:30Z<p>Dmacdona: /* Techniques */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to David MacDonald )<br />
## Status: New<br />
<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9946Wcag21-techniques2018-06-25T14:36:08Z<p>Dmacdona: /* Techniques */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to David MacDonald )<br />
## Status: New<br />
<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
# Using a string of characters in the Name that exactly matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9945Accname-matches-autocomplete2018-06-24T20:51:39Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the autocomplete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces in the place of hyphens in the autocomplete tokens. HTML 5.2 provides a [https://www.w3.org/TR/WCAG21/#input-purposes list of autocomplete tokens] written in English with hyphens to separate the words. In this technique, spaces will generally be used instead of hyphens to separate words although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technologies to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities, such as adding icons or replacing the text string with the desired string by the user. </p><br />
<p>This technique provides a way for authors to use a label for an input without having to add any further attributes in order to meet success criterion 1.3.5, Identify Input Purpose or 1.3.6, Identify Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the autocomplete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><br />
<label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p3">Address Line 1</label><br><br />
<input type="text" ... id="p3"><br><br><br />
<label for="p4">Address Line 2</label><br><br />
<input type="text" ... id="p4"><br><br><br />
<label for="p5">Postal Code</label><br><br />
<input type="text" ... id="p5"><br><br><br />
<label for="p6">Telephone</label><br><br />
<input type="text" ... id="p6"><br><br><br />
<label for="p7">Email</label><br><br />
<input type="text" ... id="p7"><br><br><br />
<label for="p8">Username</label><br><br />
<input type="text" ... id="p8"><br><br><br />
</code><br />
<p> Note: the HTML 5.2 autocomplete string for Telephone is "tel" which is contained in the string of the (Accessible) Name used.</p><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Check the text string of the (Accessible) Name </li><br />
<li>Compare it to the text string of the corresponding autocomplete attribute from HTML 5.2</li><br />
<li>Is the text string of the (Accessible) Name's corresponding autocomplete attribute from HTML 5.2 contained in the Name. (Case insensitive, hyphens can be replaced by spaces.)</li> </ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Check #2 and #3 are true the test passes and the technique has been propoerly implemented.</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9944Accname-matches-autocomplete2018-06-24T20:41:22Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the autocomplete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces in the place of hyphens in the autocomplete tokens. HTML 5.2 provides a [https://www.w3.org/TR/WCAG21/#input-purposes list of autocomplete tokens] written in English with hyphens to separate the words. In this technique, spaces will generally be used instead of hyphens to separate words although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technologies to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities, such as adding icons or replacing the text string with the desired string by the user. </p><br />
<p>This technique provides a way for authors to use a label for an input without having to add any further attributes in order to meet success criterion 1.3.5, Identify Input Purpose or 1.3.6, Identify Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the autocomplete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><br />
<label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p3">Address Line 1</label><br><br />
<input type="text" ... id="p3"><br><br><br />
<label for="p4">Address Line 2</label><br><br />
<input type="text" ... id="p4"><br><br><br />
<label for="p5">Postal Code</label><br><br />
<input type="text" ... id="p5"><br><br><br />
<label for="p6">Telephone</label><br><br />
<input type="text" ... id="p6"><br><br><br />
<label for="p7">Email</label><br><br />
<input type="text" ... id="p7"><br><br><br />
<label for="p8">Username</label><br><br />
<input type="text" ... id="p8"><br><br><br />
</code><br />
<p> Note: the HTML 5.2 autocomplete string for Telephone is "tel" which is contained in the string of the (Accessible) Name used.</p><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Check the text string of the (Accessible) Name </li><br />
<li>Compare it to the text string of the corresponding autocomplete attribute from HTML 5.2</li><br />
<li>Is the text string of the (Accessible) Name's corresponding autocomplete attribute from HTML 5.2 contained in the Name. (Case insensitive, hyphens can be replaced by spaces</li> </ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Check #2 and #3 are true the test passes and the technique has been propoerly implemented.</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9943Accname-matches-autocomplete2018-06-24T20:39:29Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the autocomplete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces in the place of hyphens in the autocomplete tokens. HTML 5.2 provides a [https://www.w3.org/TR/WCAG21/#input-purposes list of autocomplete tokens] written in English with hyphens to separate the words. In this technique, spaces will generally be used instead of hyphens to separate words although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technologies to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities, such as adding icons or replacing the text string with the desired string by the user. </p><br />
<p>This technique provides a way for authors to use a label for an input without having to add any further attributes in order to meet success criterion 1.3.5, Identify Input Purpose or 1.3.6, Identify Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the autocomplete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><br />
<label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p3">Address Line 1</label><br><br />
<input type="text" ... id="p3"><br><br><br />
<label for="p4">Address Line 2</label><br><br />
<input type="text" ... id="p4"><br><br><br />
<label for="p5">Postal Code</label><br><br />
<input type="text" ... id="p5"><br><br><br />
<label for="p6">Telephone</label><br><br />
<input type="text" ... id="p6"><br><br><br />
<label for="p7">Email</label><br><br />
<input type="text" ... id="p7"><br><br><br />
<label for="p8">Username</label><br><br />
<input type="text" ... id="p8"><br><br><br />
</code><br />
<p> Note: the HTML 5.2 autocomplete string for Telephone is "tel" which is contained in the string of the (Accessible) Name used.</p><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Check the text string of the (Accessible) Name </li><br />
<li>Compare it to the text string of the corresponding autocomplete attribute from HTML 5.2</li><br />
<li>Is the text string of the corresponding autocomplete attribute from HTML 5.2 contained in the Name. (Case insensitive, hyphens can be replaced by spaces</li> </ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Check #2 and #3 are true the test passes and the technique has been propoerly implemented.</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9942Accname-matches-autocomplete2018-06-24T13:20:45Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces replacing hyphens)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the auto complete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces. HTML 5.2 provides a list of auto complete attributes. They are written in English with hyphens to separate the words. In this technique spaces will generally be used instead although although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technology to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities. This provides way for authors to provide a label for an input without having to provide any further attributes in order to meet success criterion 1.3.5 Identify Input Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the auto complete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><br />
<label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p3">Address Line 1</label><br><br />
<input type="text" ... id="p3"><br><br><br />
<label for="p4">Address Line 2</label><br><br />
<input type="text" ... id="p4"><br><br><br />
<label for="p5">Postal Code</label><br><br />
<input type="text" ... id="p5"><br><br><br />
<label for="p6">Telephone</label><br><br />
<input type="text" ... id="p6"><br><br><br />
<label for="p7">Email</label><br><br />
<input type="text" ... id="p7"><br><br><br />
<label for="p8">Username</label><br><br />
<input type="text" ... id="p8"><br><br><br />
</code><br />
<p> Note: the HTML 5.2 autocomplete string for Telephone is "tel" which is contained in the string of the (Accessible) Name used.</p><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Check the text string of the (Accessible) Name </li><br />
<li>Compare it to the text string of the corresponding autocomplete attribute from HTML 5.2</li><br />
<li>Is the text string of the corresponding autocomplete attribute from HTML 5.2 contained in the Name. (Case insensitive, hyphens can be replaced by spaces</li> </ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Check #2 and #3 are true the test passes and the technique has been propoerly implemented.</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9941Accname-matches-autocomplete2018-06-24T13:19:37Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces replacing hyphens)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the auto complete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces. HTML 5.2 provides a list of auto complete attributes. They are written in English with hyphens to separate the words. In this technique spaces will generally be used instead although although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technology to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities. This provides way for authors to provide a label for an input without having to provide any further attributes in order to meet success criterion 1.3.5 Identify Input Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the auto complete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><br />
<label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p3">Address Line 1</label><br><br />
<input type="text" ... id="p3"><br><br><br />
<label for="p4">Address Line 2</label><br><br />
<input type="text" ... id="p4"><br><br><br />
<label for="p5">Postal Code</label><br><br />
<input type="text" ... id="p5"><br><br><br />
<label for="p6">Telephone</label><br><br />
<input type="text" ... id="p6"><br><br><br />
<label for="p7">Email</label><br><br />
<input type="text" ... id="p7"><br><br><br />
<label for="p8">Username</label><br><br />
<input type="text" ... id="p8"><br><br><br />
</code><br />
<p> Note: the HTML 5.2 autocomplete string for Telephone is "tel" which is contained in the string of the (Accessible) Name used.</p><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Check the text string of the (Accessible) Name </li><br />
<li>Compare it to the text string of the corresponding autocomplete attribute from HTML 5.2</li><br />
<li>Is the text string of the corresponding autocomplete attribute from HTML 5.2 contained in the Name, case insensitive with or without hypens replaced by spaces</li> </ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Check #2 and #3 are true the test passes and the technique has been propoerly implemented.</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9940Accname-matches-autocomplete2018-06-24T13:18:57Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces replacing hyphens)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the auto complete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces. HTML 5.2 provides a list of auto complete attributes. They are written in English with hyphens to separate the words. In this technique spaces will generally be used instead although although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technology to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities. This provides way for authors to provide a label for an input without having to provide any further attributes in order to meet success criterion 1.3.5 Identify Input Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the auto complete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><br />
<label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p3">Address Line 1</label><br><br />
<input type="text" ... id="p3"><br><br><br />
<label for="p4">Address Line 2</label><br><br />
<input type="text" ... id="p4"><br><br><br />
<label for="p5">Postal Code</label><br><br />
<input type="text" ... id="p5"><br><br><br />
<label for="p6">Telephone</label><br><br />
<input type="text" ... id="p6"><br><br><br />
<label for="p7">Email</label><br><br />
<input type="text" ... id="p7"><br><br><br />
<label for="p8">Username</label><br><br />
<input type="text" ... id="p8"><br><br><br />
</code><br />
<p> Note: the HTML 5.2 autocomplete string for Telephone is "tel" which is contained in the string of the (Accessible) Name used.</p><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Check the text string(Accessible) Name </li><br />
<li>Compare it to the text string of the corresponding autocomplete attribute from HTML 5.2</li><br />
<li>Is the text string of the corresponding autocomplete attribute from HTML 5.2 contained in the Name, case insensitive with or without hypens replaced by spaces</li> </ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Check #2 and #3 are true the test passes and the technique has been propoerly implemented.</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9939Accname-matches-autocomplete2018-06-24T13:18:21Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces replacing hyphens)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the auto complete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces. HTML 5.2 provides a list of auto complete attributes. They are written in English with hyphens to separate the words. In this technique spaces will generally be used instead although although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technology to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities. This provides way for authors to provide a label for an input without having to provide any further attributes in order to meet success criterion 1.3.5 Identify Input Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the auto complete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><br />
<label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p3">Address Line 1</label><br><br />
<input type="text" ... id="p3"><br><br><br />
<label for="p4">Address Line 2</label><br><br />
<input type="text" ... id="p4"><br><br><br />
<label for="p5">Postal Code</label><br><br />
<input type="text" ... id="p5"><br><br><br />
<label for="p6">Telephone</label><br><br />
<input type="text" ... id="p6"><br><br><br />
<label for="p7">Email</label><br><br />
<input type="text" ... id="p7"><br><br><br />
<label for="p8">Username</label><br><br />
<input type="text" ... id="p8"><br><br><br />
</code><br />
<p> Note: the HTML 5.2 autocomplete string for Telephone is "tel" which is contained in the string of the (Accessible) Name used.<br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Check the text string(Accessible) Name </li><br />
<li>Compare it to the text string of the corresponding autocomplete attribute from HTML 5.2</li><br />
<li>Is the text string of the corresponding autocomplete attribute from HTML 5.2 contained in the Name, case insensitive with or without hypens replaced by spaces</li> </ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Check #2 and #3 are true the test passes and the technique has been propoerly implemented.</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9938Accname-matches-autocomplete2018-06-24T13:16:19Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces replacing hyphens)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the auto complete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces. HTML 5.2 provides a list of auto complete attributes. They are written in English with hyphens to separate the words. In this technique spaces will generally be used instead although although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technology to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities. This provides way for authors to provide a label for an input without having to provide any further attributes in order to meet success criterion 1.3.5 Identify Input Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the auto complete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><br />
<label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p3">Address Line 1</label><br><br />
<input type="text" ... id="p3"><br><br><br />
<label for="p4">Address Line 2</label><br><br />
<input type="text" ... id="p4"><br><br><br />
<label for="p5">Postal Code</label><br><br />
<input type="text" ... id="p5"><br><br><br />
<label for="p6">Telephone</label><br><br />
<input type="text" ... id="p6"><br><br><br />
<label for="p7">Email</label><br><br />
<input type="text" ... id="p7"><br><br><br />
<label for="p8">Username</label><br><br />
<input type="text" ... id="p8">obv<br><br><br />
<br />
<br />
</code><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Check the text string(Accessible) Name </li><br />
<li>Compare it to the text string of the corresponding autocomplete attribute from HTML 5.2</li><br />
<li>Is the text string of the corresponding autocomplete attribute from HTML 5.2 contained in the Name, case insensitive with or without hypens replaced by spaces</li> </ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Check #2 and #3 are true the test passes and the technique has been propoerly implemented.</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9937Accname-matches-autocomplete2018-06-24T11:50:18Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces replacing hyphens)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the auto complete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces. HTML 5.2 provides a list of auto complete attributes. They are written in English with hyphens to separate the words. In this technique spaces will generally be used instead although although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technology to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities. This provides way for authors to provide a label for an input without having to provide any further attributes in order to meet success criterion 1.3.5 Identify Input Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the auto complete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p2">Family Name</label><br><br />
<input type="text" ... id="p2"><br><br><br />
<label for="p3">Username</label><br><br />
<input type="text" ... id="p3">obv<br><br><br />
<br />
<br />
</code><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Step 1</li><br />
</ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Result</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9936Accname-matches-autocomplete2018-06-24T11:49:30Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces replacing hyphens)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the auto complete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces. HTML 5.2 provides a list of auto complete attributes. They are written in English with hyphens to separate the words. In this technique spaces will generally be used instead although although hyphens would be acceptable also. In this technique it is also sufficient to use capital letters as appropriate in the accessible name.</p><br />
<p>The objective of this technique is to allow assistive technology to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities. This provides way for authors to provide a label for an input without having to provide any further attributes in order to meet success criterion 1.3.5 Identify Input Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the auto complete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code><label for="p1">Given Name</label><br />
<input type="text" ... id="p1"><br />
<label for="p2">Family Name</label><br />
<input type="text" ... id="p2"><br />
<label for="p2">Family Name</label><br />
<input type="text" ... id="p2"><br />
<label for="p3">Username</label><br />
<input type="text" ... id="p3"><br />
<br />
<br />
</code><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Step 1</li><br />
</ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Result</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9935Accname-matches-autocomplete2018-06-24T11:43:11Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces replacing hyphens)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the auto complete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces. HTML 5.2 provides a list of auto complete attributes. They are written in English with hyphens to separate the words. In this technique spaces will generally be used instead although f hyphens although hyphens would be acceptable also. </p><br />
<p>The objective of this technique is to allow assistive technology to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities. This provides way for authors to provide a label for an input without having to provide any further attributes in order to meet success criterion 1.3.5 Identify Input Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the auto complete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code>Code sample</code><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Step 1</li><br />
</ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Result</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9934Accname-matches-autocomplete2018-06-24T11:39:02Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the (Accessible) Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces allowed)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions"> This technique works in technologies that provide an accessible name. </p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">The accessible name is a programmatically determinable string of text which can be used in place of the auto complete attribute on input elements. In order to use this technique, the accessible name string would have to be identical the corresponding autocomplete string, except for the insertion of spaces. </p><br />
<p>The objective of this technique is to allow assistive technology to examine the accessible name as an alternative to the autocomplete attributes when providing supports for people with cognitive disabilities. This provides way for authors to provide a label for an input without having to provide any further attributes in order to meet success criterion 1.3.5 Identify Input Purpose. Naturally, authors should use this technique only for fields where the string of text that makes up the corresponding HTML 5.2 autocomplete attribute is a logical name that they would've chosen anyway. This technique generally applies to the English language because the auto complete attributes are written using strings of English text. </p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions"></p><br />
<section class="example"><br />
<h3>Example 1: Simple contact form First Name and Last Name</h3><br />
<p>Description</p><br />
<code>Code sample</code><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Step 1</li><br />
</ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Result</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9933Accname-matches-autocomplete2018-06-24T11:25:55Z<p>Dmacdona: </p>
<hr />
<div><h1>Using a string of characters in the Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces allowed)</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions">Describe the situations in which to use the technique, such as types of pages, features in use that might use the technique, etc.</p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">Describe how the technique works. This begins with a description of the problem the technique solves, then describes how to apply the technique. The description should be detailed enough to provide all the information a reader needs to be able to apply the technique, without recourse to following example code.</p><br />
<p>The objective of this technique is to ...</p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions">Copy the following section for each example. Examples must have a title and a description, and usually have a code sample. Code samples should be elided if necessary to show the core of the technique without necessarily providing all the surrounding code that would also be involved. A working example link references a location where the technique can be shown working live.</p><br />
<section class="example"><br />
<h3>Example Title</h3><br />
<p>Description</p><br />
<code>Code sample</code><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Step 1</li><br />
</ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Result</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Accname-matches-autocomplete&diff=9932Accname-matches-autocomplete2018-06-24T11:18:21Z<p>Dmacdona: Created page with "= Using a string of characters in the Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces allowed) = <h1>Using HTML 5.2 autocomplete..."</p>
<hr />
<div>= Using a string of characters in the Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces allowed) =<br />
<h1>Using HTML 5.2 autocomplete attributes</h1><br />
<section id="meta"><br />
<h2>Metadata</h2><br />
<p id="id"></p><br />
<p id="technology">html</p><br />
<p id="type">sufficient</p><br />
</section><br />
<section id="applicability"><br />
<h2>When to Use</h2><br />
<p class="instructions">Describe the situations in which to use the technique, such as types of pages, features in use that might use the technique, etc.</p><br />
</section><br />
<section id="description"><br />
<h2>Description</h2><br />
<p class="instructions">Describe how the technique works. This begins with a description of the problem the technique solves, then describes how to apply the technique. The description should be detailed enough to provide all the information a reader needs to be able to apply the technique, without recourse to following example code.</p><br />
<p>The objective of this technique is to ...</p><br />
</section><br />
<section id="examples"><br />
<h2>Examples</h2><br />
<p class="instructions">Copy the following section for each example. Examples must have a title and a description, and usually have a code sample. Code samples should be elided if necessary to show the core of the technique without necessarily providing all the surrounding code that would also be involved. A working example link references a location where the technique can be shown working live.</p><br />
<section class="example"><br />
<h3>Example Title</h3><br />
<p>Description</p><br />
<code>Code sample</code><br />
<p>Working example: link</p><br />
</section><br />
</section><br />
<section id="tests"><br />
<h2>Tests</h2><br />
<section class="test-procedure"><br />
<h3>Procedure</h3><br />
<ol><br />
<li>Step 1</li><br />
</ol><br />
</section><br />
<section class="test-results"><br />
<h3>Expected Results</h3><br />
<ul><br />
<li>Result</li><br />
</ul><br />
</section><br />
</section><br />
<section id="related"><br />
<h2>Related Techniques</h2><br />
<ul><br />
<li>ID</li><br />
</ul><br />
</section></div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9931Wcag21-techniques2018-06-24T11:16:37Z<p>Dmacdona: /* Techniques */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
# Using a string of characters in the Name that exactly matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
* Status: New [[accname-matches-autocomplete]]<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
# Using a string of characters in the Name that exactly matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9930Wcag21-techniques2018-06-24T11:15:07Z<p>Dmacdona: /* Techniques */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
# [accname-matches-autocomplete] Using a string of characters in the Name that exactly matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
* Status: New<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
# Using a string of characters in the Name that exactly matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9929Wcag21-techniques2018-06-24T10:59:32Z<p>Dmacdona: /* Identify Purpose */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
# Using a string of characters in the Name that exactly matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
* Status: New<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
# Using a string of characters in the Name that exactly matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9928Wcag21-techniques2018-06-24T10:57:50Z<p>Dmacdona: /* Identify Input Purpose */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
# Using a string of characters in the Name that exactly matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
* Status: New<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9927Wcag21-techniques2018-06-24T10:57:27Z<p>Dmacdona: /* Identify Input Purpose */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
# [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
# Using a string of characters in the Name that exactly matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
# Status: New<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9926Wcag21-techniques2018-06-24T10:56:02Z<p>Dmacdona: /* Identify Input Purpose */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
* Using a string of characters in the Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces inserted) (Assigned to David MacDonald)<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9925Wcag21-techniques2018-06-24T10:52:20Z<p>Dmacdona: /* Identify Input Purpose */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
* Using a string of characters in the Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces allowed)<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9924Wcag21-techniques2018-06-24T10:51:55Z<p>Dmacdona: /* Techniques */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
* Using a string of characters in the Accessible Name that matches the string in the corresponding HTML5.2 autocomplete attributes (with spaces allowed)<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9923Wcag21-techniques2018-06-24T10:50:48Z<p>Dmacdona: /* Identify Input Purpose */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
* Using a string of characters in the Accessible Name that matches the string in the autocomplete except for spaces<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: [[Text given viewport units that does not rescale]]<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory) (Assigned to Jake)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html "Text spacing"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review: [https://rawgit.com/w3c/wcag/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag/blob/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
* Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Setting a session timeout to occur following 24 hours of inactivity.<br />
## Status: New<br />
# Store user data for more than 20 hours.<br />
## Status: New<br />
# Provide a warning of the duration of user inactivity at the start of a process.<br />
## Status: New<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names] | [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html View in rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Drafted]<br />
# [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure: Accessible Name does not contain the visible label text] | [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html View in Rawgit] (Assigned to Detlev)<br />
## Status: [https://rawgit.com/w3c/wcag21/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Drafted]<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# '''Probably needs to be removed, this is not a fauilure''' (Detlev). Compare [https://github.com/w3c/wcag21/pull/956 pull request]. Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": [https://github.com/w3c/wcag/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html GXXX: Not relying on path-based gestures] | [https://rawgit.com/w3c/wcag/tech-not-path-gestures/techniques/general/not-path-gestures.html View in RawGit] (Assigned to Detlev )<br />
## Status: New<br />
# '''I think this is redundant''', already covered by "Ensuring that multi-point and path-based gesture...": GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: [https://github.com/w3c/wcag/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer] | [https://rawgit.com/w3c/wcag/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html View in rawgit] (Assigned to Detlev)<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to Detlev )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# GXXX: [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled] | [https://rawgit.com/w3c/wcag21/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html View in rawgit] (Assigned to Detlev )<br />
## Status: Draft moved to from Wiki to Github 2018/05/17<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to Marc Johlic )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
The overall process is:<br />
<br />
# Decide on a technique to work on, put your name next to it in the page above.<br />
# Work on it either in new GitHub branch or on the wiki (see below).<br />
# Tell the chairs when you think it is ready (you may have already worked with others by this point, or not).<br />
# Chairs will make PR from branch or make the branch and then make the PR.<br />
# Submitter announces the idea to the group as an idea that needs additional reviewers (chairs can help if needed).<br />
# Once there are 5 total people (author plus 4) on the group that approve the wording of the new technique, or change to a technique or understanding document, then the submitter lets the chairs know that it is ready (the 5 people should not all be from a single TF).<br />
# Chairs will make a survey. Survey will have Accept as Sufficient Technique/Accept as Advisory Technique/Accept as ST with changes/Accept as AT with changes/Do not accept yet and will require people to comment in Github.<br />
# If the "done" message is received by Friday morning at 11am ET then it will be released for the following week's schedule.<br />
# Unless there are substantial comments that cannot be resolved in time, including on the Tuesday call, the technique or change will be merged to the editor's draft for publication as soon as possible.<br />
# If there are major problems or major changes that the group believes requires additional review, the process for review repeats<br />
<br />
There is general guidance on writing techniques: [[Techniques|Technique writing resources]], see especially the [[Writing_WCAG_Techniques_-_Notes|writing notes]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.<br />
<br />
=== Wikitext version ===<br />
<br />
If you are not confident with creating things in Github, then you can also use the wiki as a method of writing a technique, and someone can help get it into the repository.<br />
<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-techniques&diff=9845Wcag21-techniques2018-05-15T16:38:48Z<p>Dmacdona: /* Techniques */</p>
<hr />
<div>[[Category: WCAG 2.1]]<br />
<br />
Page to track the creation and review of ''new'' techniques & failures for WCAG 2.1.<br />
<br />
== Process ==<br />
<br />
* Volunteer (or be assigned) one or more techniques from the list below. Feel free to put your name against one. Task forces are the primary leaders for their success criteria, please contact the TF facilitators if you want to volunteer for a technique.<br />
* Draft the technique, either:<br />
** Create in the wiki by copying the content of the [[Technique Template|template]].<br />
** Editing the appropriate branch in Github (instructions below).<br />
* Link to the draft technique by editing the page below.<br />
* The drafts will be reviewed by the AG working group.<br />
<br />
NB: '''To find the branch in github''', go to the [https://github.com/w3c/wcag21/ main repository page] and use the branch drop-down. Type in a keyword to find the correct branch, and drill down the files to the technique document.<br />
<br />
===Understanding Document tracking===<br />
See https://www.w3.org/WAI/GL/wiki/Wcag21-understanding-documents<br />
<br />
== List of Techniques ==<br />
<br />
===Identify Input Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-input-purpose/understanding/21/identify-input-purpose.html "Identify Input Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# [https://github.com/w3c/wcag21/blob/tech-autocomplete/techniques/html/autocomplete.html Use HTML5.2 autocomplete attributes] (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-autocomplete/techniques/html/autocomplete.html Using HTML 5.2 autocomplete attributes]<br />
<br />
===Identify Purpose===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/identify-purpose/understanding/21/identify-purpose.html "Identify Purpose"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using aui- semantics for controls (Assigned to TBC )<br />
## Status: New (guessed technique)<br />
# Use of landmarks (Assigned to TBC )<br />
## Status: New (do we have one already?)<br />
# Marking up icons (Assigned to TBC )<br />
## Status: New (guess techinque)<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-personalization-semantics-controls/techniques/personalization/personalization-semantics-controls.html Using personalization semantics for controls]<br />
* [https://github.com/w3c/wcag21/tree/tech-landmarks/techniques/html/landmarks.html Using HTML 5 landmarks]<br />
<br />
===Reflow===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/reflow/understanding/21/reflow.html "Reflow"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Using media queries and grid CSS to reflow columns (Assigned to Jake Abma )<br />
## Status: New<br />
# Failure: Text given viewport units that does not rescale (New)<br />
## Status: New<br />
# Allowing for Reflow<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Allowing_for_Reflow "Drafted"] Assigned to Laura<br />
# Using CSS Flexbox to reflow content (Assigned to Jake)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Using_CSS_Flexbox_to_reflow_content Not started]<br />
# Using vertical media queries to un-fix sticky headers / footers (New, advisory)<br />
## Status: New<br />
# CSS, Fitting images to the viewport; (new)<br />
## Status: New<br />
# CSS, Reflowing simple data tables.(new)<br />
## Status: New<br />
# CSS, Fitting data cells within the width of the viewport. (new)<br />
## Status: New<br />
# Using flexible text input form control (new)<br />
## Status New<br />
# Mechanism to allow mobile view at any time (new)<br />
## Status: New <br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-grid-reflow/techniques/css/media-queries-grid-reflow.html Using media queries and grid CSS to reflow columns]<br />
* [https://github.com/w3c/wcag21/tree/tech-reflow/techniques/css/reflow.html Allowing for Reflow]<br />
* [https://github.com/w3c/wcag21/tree/tech-flexbox-reflow/techniques/css/flexbox-reflow.html Using CSS Flexbox to reflow content]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-16-px-not-wrap/techniques/css/failure-16-px-not-wrap.html Failure due to using a font of 16 px that does not wrap]<br />
<br />
===Non-text Contrast===<br />
Understanding document: [http://rawgit.com/w3c/wcag21/non-text-contrast/understanding/21/non-text-contrast.html "Non-text contrast"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Contrasting colors between graphical objects (Assigned to TBC )<br />
## Status: New<br />
# Include contrasting lines between adjoining colors (Assigned to TBC )<br />
## Status: New<br />
# Include labels and values with the graphic (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-contrast-graphical-objects/techniques/general/contrast-graphical-objects.html Contrasting colors between graphical objects] <br />
* [https://github.com/w3c/wcag21/tree/tech-contrasting-lines/techniques/general/contrasting-lines.html Including contrasting lines between adjoining colors]<br />
* [https://github.com/w3c/wcag21/tree/tech-labels-values-graphic/techniques/general/labels-values-graphic.html Including labels and values with the graphic]<br />
<br />
===Text Spacing===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/text-spacing/understanding/21/text-spacing.html "Text spacing"] <br />
<br />
====Techniques====<br />
# Allowing for Spacing Override (Assigned to Laura )<br />
## Status: Ready for review<br />
## [https://rawgit.com/w3c/wcag21/tech-spacing-override/techniques/css/spacing-override.html View] | [https://github.com/w3c/wcag21/tree/tech-spacing-override/techniques/css/spacing-override.html Edit]<br />
<br />
===Content on Hover or Focus===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/content-on-hover-or-focus/understanding/21/content-on-hover-or-focus.html "Content on Hover or Focus"] <br />
<br />
## Status: <br />
====Techniques====<br />
# ARIA Using role=tooltip (Assigned to TBC )<br />
## Status: New<br />
# CSS: Using hover and focus pseudo classes (Assigned to TBC )<br />
## Status: New<br />
# Failure to make content dismissable without moving pointer hover or keyboard focus (Assigned to TBC )<br />
## Status: New<br />
# Failure to have hover content hoverable (Assigned to TBC )<br />
## Status: New<br />
# Failure to meet by content on hover or focus not remaining visible until dismissed or invalid (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-tooltip-role/techniques/aria/tooltip-role.html Using the tooltip role]<br />
* [https://github.com/w3c/wcag21/tree/tech-hover-focus/techniques/css/hover-focus.html Using hover and focus pseudo-classes]<br />
<br />
===Timeouts===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/timeouts/understanding/21/timeouts.html "Timeouts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# TBC (Assigned to TBC )<br />
## Status: New<br />
<br />
<br />
=== Animation from Interactions ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/animation-from-interactions/understanding/21/animation-from-interactions.html "Animation from Interactions"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Gx: Allowing users to set a preference that prevents animation (Assigned to TBC )<br />
## Status: New<br />
# CSS x: User reduce motion CSS media query to prevent animation for people that set it. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-preference-prevent-animation/techniques/general/preference-prevent-animation.html Providing a preference to prevent animation]<br />
* [https://github.com/w3c/wcag21/tree/tech-prefers-reduced-motion/techniques/css/prefers-reduced-motion.html Using the prefers-reduced-motion media query]<br />
<br />
=== Character Key Shortcuts ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/character-key-shortcuts/understanding/21/character-key-shortcuts.html "Character Key Shortcuts"] <br />
<br />
* Status: <br />
====Techniques====<br />
# Users have a way to turn off single-key shortcuts (Assigned to TBC )<br />
## Status: New<br />
<br />
# A mechanism is provided to allow users to change character-key shortcuts. (Assigned to TBC )<br />
## Status: New<br />
<br />
# Using an unmodifiable single-key shortcut (Assigned to TBC )<br />
## Status: New Failure<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-turn-off-single-key-shortcuts/techniques/general/turn-off-single-key-shortcuts.html Providing a mechanism to turn off single-key shortcuts] <br />
* [https://github.com/w3c/wcag21/tree/tech-change-single-key-shortcuts/techniques/general/change-single-key-shortcuts.html Providing a mechanism to change character-key shortcuts]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-unmodifiable-single-key-shortcut/techniques/general/failure-unmodifiable-single-key-shortcut.html Failure due to using an unmodifiable single-key shortcut]<br />
<br />
===Label in Name===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/label-in-name/understanding/21/label-in-name.html "Label in Name"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensure that visible labels match their accessible names (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name does not contain the visible label text (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but the words of the visible label are not in the same order as they are in the visible label text. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words is interspersed in the label (Assigned to TBC )<br />
## Status: New<br />
# Failure: Accessible Name contains the visible label text, but one or more other words comes before the visible label text (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-visible-labels-match-names/techniques/general/visible-labels-match-names.html Ensuring that visible labels match their accessible names]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-label-text/techniques/general/failure-name-not-label-text.html Failure due to accessible name not containing the visible label text]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-not-same-order/techniques/general/failure-name-not-same-order.html Failure due to accessible name containing the visible label text but with words not in the same order]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-interspersed/techniques/general/failure-name-words-interspersed.html Failure due to accessible name containing the visible label text but with one or more other words interspersed]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-name-words-preceding/techniques/general/failure-name-words-preceding.html Failure due to accessible name containing the visible label text but with one or more other words preceding the visible label text]<br />
<br />
===Target Size===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/target-size/understanding/21/target-size.html "Target Size"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Ensuring that touch targets are at least 44 by 44 CSS pixels (Assigned to TBC )<br />
## Status: New<br />
# Providing a mechanism to change the size of the target independent of magnification. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Target size less than 44 x 44 CSS px for buttons and controls (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-targets-44-by-44/techniques/general/touch-targets-44-by-44.html Ensuring that touch targets are at least 44 by 44 pixels]<br />
* [https://github.com/w3c/wcag21/tree/tech-change-target-size-magnification/techniques/general/change-target-size-magnification.html Providing a mechanism to change target sizes independent of magnification]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-small-target-size/techniques/general/failure-small-target-size.html Failure due to target size less than 44 x 44 px for buttons and controls]<br />
<br />
===Pointer Gestures===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-gestures/understanding/21/pointer-gestures.html "Pointer Gestures"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not rely on path-based gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Do not rely on multi-point gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Single-point activation for spatial positioning and manipuation (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Ensuring that functionality triggered by multipoint or path-based gestures can be operated with a single pointer (Assigned to Detlev)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Ensuring_that_functionality_triggered_by_multipoint_or_path-based_gestures_can_be_operated_with_a_single_pointer Drafted in wiki 2018-02-28]<br />
# Failure: Functionality can be operated by pointer input but not with single-point activation alone (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-not-path-gestures/techniques/general/not-path-gestures.html Not relying on path-based gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-not-multi-point-gestures/techniques/general/not-multi-point-gestures.html Not relying on multi-point gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-replace-complex-gestures/techniques/general/replace-complex-gestures.html Providing controls to replace complex gestures]<br />
* [https://github.com/w3c/wcag21/tree/tech-single-point-activation-spatial/techniques/general/single-point-activation-spatial.html Providing single-point activation for spatial positioning and manipuation]<br />
* [https://github.com/w3c/wcag21/tree/tech-ensuring-single-pointer/techniques/general/ensuring-single-pointer.html Ensuring that multi-point and path-based gesture functionality can be operated with a single pointer]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-pointer-input-not-single-pointer/techniques/general/failure-pointer-input-not-single-pointer.html Failure due to functionality can be operated by pointer input but not with single-pointer activation alone]<br />
<br />
=== Pointer Cancellation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/pointer-cancellation/understanding/21/pointer-cancellation.html "Pointer Cancellation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Activating a control using the up-Event in HTML, iOS and Android (Assigned to TBC )<br />
## Status: New<br />
# M029(wiki) Touch events are only triggered when touch is removed from a control (Assigned to TBC )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/M029 "Drafted"]<br />
# Ensuring that drag-and-drop gestures can be cancelled (Assigned to Detlev )<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Ensuring_that_drag-and-drop_gestures_can_be_cancelled "Drafted"]<br />
# Activation events are not triggered when touch is removed from a control (Assigned to Chris)<br />
## Status: [https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Activation_events_are_not_triggered_when_touch_is_removed_from_a_control "Drafted in wiki 2018-03-29"]<br />
# Failure: FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location (Assigned to TBC )<br />
## Status: [http://w3c.github.io/Mobile-A11y-TF-Note/Techniques/FM001 "Drafted"]<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-control-up-event/techniques/client-side-script/control-up-event.html Activating a control using the up-event]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-events-touch-removed/techniques/general/touch-events-touch-removed.html Triggering touch events only when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-drag-drop-cancel/techniques/general/drag-drop-cancel.html Ensuring that drag-and-drop gestures can be cancelled]<br />
* [https://github.com/w3c/wcag21/tree/tech-touch-removed-no-activation/techniques/general/touch-removed-no-activation.html Not triggering activation events when touch is removed from a control]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-initial-touch-location/techniques/general/failure-initial-touch-location.html Failure due to activating a button on initial touch location rather than final touch location]<br />
<br />
=== Concurrent Input Mechanisms===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/concurrent-input-mechanisms/understanding/21/concurrent-input-mechanisms.html "Concurrent Input Mechanisms"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Only using high-level, input-agnostic event handlers (focus, blur, click) in Javascript (operating systems/UAs fire these events for all input mechanisms). (Assigned to TBC )<br />
## Status: New<br />
# Registering event handlers for keyboard/keyboard-like and pointer inputs simultaneously in Javascript. (Assigned to TBC )<br />
## Status: New, see [https://w3c.github.io/pointerevents/#examples "Example 1 in Pointer Events Level 2"]<br />
# Failure: Registering either touch event handlers or keyboard/mouse event handlers based on a feature check/presence of a touchscreen in Javascript. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Using CSS Media Queries Level 4 Interaction Media Features to determine what the UA deems to be the "primary" input mechanism and assuming no other input mechanisms are present/may be added/may be used. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-input-agnostic-events/techniques/client-side-script/input-agnostic-events.html Only using input-agnostic event handlers]<br />
* [https://github.com/w3c/wcag21/tree/tech-keyboard-pointer-events-simultaneous/techniques/client-side-script/keyboard-pointer-events-simultaneous.html Registering event handlers for keyboard and pointer inputs simultaneously]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-touch-feature-check/techniques/client-side-script/failure-touch-feature-check.html Failure due to registering touch event handlers or keyboard and mouse event handlers based on a feature check or presence of a touchscreen]<br />
* [https://github.com/w3c/wcag21/tree/tech-media-queries-primary-input/techniques/client-side-script/media-queries-primary-input.html "Using CSS Media Queries to determine the ""primary"" input mechanism"]<br />
<br />
=== Orientation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/orientation/understanding/21/orientation.html "Orientation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using CSS to set the orientation to allow both landscape and portrait. (Assigned to TBC )<br />
## Status: New<br />
# Use of show/hide controls to allow access to content in different orientations. (Assigned to TBC )<br />
## Status: New<br />
# Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations. (Assigned to )<br />
## Status: New<br />
# Failure: Locking the orientation. (Assigned to TBC )<br />
## Status: New<br />
# Failure: Functionality that is only available in one orientation. (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-orientation-both/techniques/css/orientation-both.html Setting the orientation to allow both landscape and portrait]<br />
* [https://github.com/w3c/wcag21/tree/tech-show-hide-different-orientations/techniques/general/show-hide-different-orientations.html Using show and hide controls to allow access to content in different orientations]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-orientation-lock/techniques/general/failure-orientation-lock.html Failure due to locking the orientation]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-functionality-one-orientation/techniques/general/failure-functionality-one-orientation.html Failure due to functionality that is only available in one orientation]<br />
<br />
=== Motion Actuation ===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/motion-actuation/understanding/21/motion-actuation.html "Motion Actuation"] <br />
<br />
* Status:<br />
====Techniques====<br />
# GXXX: Do not use the devicemotion event to activate content functionality (Assigned to TBC )<br />
## Status: New<br />
# GXXX: Ensure that alternative means of input exist when using device motion sensor input to activate content functionality (Assigned to TBC )<br />
## Status: New<br />
# FXXX: Content functionality can only be activated via input from devicemotion events (e.g. shaking or tilting) (Assigned to TBC )<br />
## Status: New<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-avoid/techniques/client-side-script/devicemotion-event-avoid.html Not using the devicemotion event to activate content functionality]<br />
* [https://github.com/w3c/wcag21/tree/tech-devicemotion-event-alternate/techniques/general/devicemotion-event-alternate.html Ensuring that alternative means of input exist when using device motion sensor input]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-device-motion-event-only/techniques/client-side-script/failure-device-motion-event-only.html Failure due to content functionality that can only be activated via input from devicemotion events]<br />
<br />
===Status Changes===<br />
Understanding document: [https://rawgit.com/w3c/wcag21/status-messages/understanding/21/status-messages.html "Status Changes"] <br />
<br />
* Status:<br />
====Techniques====<br />
# Using role=status (Assigned to TBC )<br />
## Status: New (NB: Not sure which need creating from the understanding doc.)<br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# G199 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# ARIA19 (Assigned to TBC )<br />
## Status: review of current technique needed <br />
# Using role="log" (Assigned to TBC )<br />
## Status: New <br />
# Using role="timer" (Assigned to TBC )<br />
## Status: New <br />
# Using role="progressbar" (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using a visibilitychange event to hide or display a document without switching the document's live regions between active and inactive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Using role=alert or aria-live=assertive on content which is not important and time-sensitive (Assigned to TBC )<br />
## Status: New <br />
# Failure: Failure of Success Criteria ### due to providing a visible status message without providing a way for assistive technology to announce these changes without focusing on them.<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-alert-assertive/techniques/aria/failure-alert-assertive.html "Failure due to using the ""alert"" role or or the ""assertive"" value of aria-live incorrectly"]<br />
* [https://github.com/w3c/wcag21/tree/tech-failure-visibility-change-event/techniques/client-side-script/failure-visibility-change-event.html Failure due to using the visibilitychange event to hide or display a document]<br />
<br />
=== Unknown SC ===<br />
<br />
* [https://github.com/w3c/wcag21/tree/tech-icon-font-img-role/techniques/aria/icon-font-img-role.html "Semantically identifying an icon font with the ""img"" role"]<br />
<br />
===Conformance===<br />
Understanding document: <br />
<br />
Related to: [https://github.com/w3c/wcag21/issues/297 Issue 297]: "Add technique for identifying CSS generated content-images" <br />
<br />
* Status:<br />
====Techniques====<br />
# Providing a Semantically Identified Icon Font with role="img" (Assigned to Laura )<br />
## Status: [https://www.w3.org/WAI/GL/wiki/Providing_a_Semantically_Identified_Icon_Font_with_role%3Dimg "Drafted"]<br />
<br />
== Creating Technique documents ==<br />
<br />
There are two methods to create technique documents:<br />
# Create in the wiki by copying the content of the [[Technique Template|Technique Template]].<br />
## Give it the same name as in the listing above.<br />
## Let the chairs know you've created it (so it can be copied into github).<br />
# Create it in github, steps below.<br />
<br />
[[Techniques|Technique writing resources]].<br />
<br />
=== Github step-by-step ===<br />
<br />
[[File:Github branch dropdown.png|frame|right]]<br />
<br />
'''Step 1:''' Go to the working branch (this is '''important'''!). E.g. To create the 'Use HTML5.2 autocomplete attributes' technique, go to the [https://github.com/w3c/wcag21/ github repo] and use the branch-select drop-down. Type in a keyword such as 'auto' and it will show the tech-autocomplete branch. Select the branch, and drill-down to the HTML page for editing (there should be only one).<br />
<br />
==== Initial creation ====<br />
<br />
To create the technique you can edit the working branch (e.g. tech-autocomplete), either in the github website interface, or in a text editor.<br />
<br />
'''Step 2:''' Click the edit button (pen icon, top right). Make your edits, and save it at the bottom by "Commit changes". Give it a little description of the changes made, e.g. "initial draft". <br />
<br />
Add a comment to this wiki page, saying you've updated it.<br />
<br />
==== Reviews and alternative versions ====<br />
<br />
For more significant edits after creation (e.g. you are reviewing someone elses technique and want to make significant changes) create a new branch to work in. '''Do step 1 first''', select the working branch.<br />
<br />
'''Step 2a:''' Select the branch drop down and start typing the name of the branch. E.g. 'tech-autocomplete', but add your name at the end. E.g. 'tech-autocomplete-alastair', and select 'Create new branch'.<br />
<br />
'''Step 3a:''' Navigate to the file and edit it. You may wish to copy-paste the whole thing into a text-editor, make changes, then copy back. Save changes by committing them.<br />
<br />
'''Step 4a:''' Create a pull request (link, top-right). Make sure the first option is the working branch (e.g. 'non-text-contrast') and the second is your new branch. It will also help to reference that pull request in the thread for the Understanding document. E.g. pull request 876 can be referenced by adding a comment that includes #876.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-understanding-documents&diff=9695Wcag21-understanding-documents2018-04-21T16:41:06Z<p>Dmacdona: /* Understanding Status Changes */</p>
<hr />
<div>The AGWG need to review and update the new understanding documents for WCAG 2.1<br />
<br />
The survey for approval will be used towards the end of the process, in the meantime, please put yourself down for reviewing one or more docs. [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Directions from Alastair's email]: <br />
<br />
<blockquote><br />
The basics to cover are:<br />
<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]<br />
* Does it provide understanding of the SC! (It is especially helpful if you sign up for one you’re less familiar with.)<br />
* Are there errors or phrasing issues (editorial);<br />
* Does it list enough techniques? (Techniques will be the next step, we don’t expect them to exist yet, but we should know what they are.)<br />
<br />
Follow the link to add comments in the main github thread.<br />
<br />
If you are confident with github please do make the updates to the doc directly. If they are significant edits (e.g. adding/removing sections) please create a branch off from the understanding-doc branch and then submit a merge request. (Email the chairs if you’d like help with that.)<br />
<br />
Otherwise, comments in github with suggested updates are good, as are documents attached with track changes / comments.<br />
<br />
</blockquote><br />
<br />
For editorial questions please refer to the [https://www.w3.org/WAI/PF/editors/style_editorial PF editors style guide].<br />
<br />
== List of understanding docs ==<br />
<br />
=== Understanding Identify Common Purpose ===<br />
https://github.com/w3c/wcag21/issues/779<br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Identify Purpose ===<br />
https://github.com/w3c/wcag21/issues/780 <br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Reflow ===<br />
https://github.com/w3c/wcag21/issues/781<br />
<br />
Reviewers: Jake Abma, Jim Allan<br />
<br />
=== Understanding Non-text Contrast ===<br />
https://github.com/w3c/wcag21/issues/782<br />
<br />
Reviewers: Mike Elledge, Mike Gower<br />
<br />
=== Understanding Text Spacing ===<br />
https://github.com/w3c/wcag21/issues/783<br />
<br />
Reviewer: Laura Carlson (Done April 18, 2018)<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]: Yes<br />
* Does it provide understanding of the SC?: Yes<br />
* Are there errors or phrasing issues (editorial)?: None that I detected.<br />
* Does it list enough techniques? I think so.<br />
<br />
Reviewer: E.A. Draffan<br />
<br />
=== Understanding Content on Hover or Focus ===<br />
https://github.com/w3c/wcag21/issues/784<br />
<br />
Reviewers: Mike Gower (completed), SteveRep<br />
<br />
=== Understanding Timeouts ===<br />
https://github.com/w3c/wcag21/issues/785<br />
<br />
Reviewers: John Kirwood<br />
<br />
=== Understanding Animation from Interactions ===<br />
https://github.com/w3c/wcag21/issues/786<br />
<br />
Reviewers: Glenda Sims (1st pass done, creating pull request next)<br />
<br />
=== Understanding Character Key Shortcuts ===<br />
https://github.com/w3c/wcag21/issues/787<br />
<br />
Reviewers: David MacD<br />
I've completed the review and made a [https://github.com/w3c/wcag21/pull/870 pull request]<br />
<br />
=== Understanding Label in Name ===<br />
https://github.com/w3c/wcag21/issues/788<br />
<br />
Reviewers: Marc Johlic<br />
<br />
=== Understanding Target Size ===<br />
https://github.com/w3c/wcag21/issues/789<br />
<br />
Reviewers: Jake Abma<br />
<br />
=== Understanding Pointer Gestures ===<br />
https://github.com/w3c/wcag21/issues/790<br />
<br />
Reviewers: Greg Lowney.<br />
<br />
=== Understanding Pointer Cancellation ===<br />
https://github.com/w3c/wcag21/issues/791<br />
<br />
Reviewers: SteveRep<br />
<br />
=== Understanding Concurrent Input Mechanisms ===<br />
https://github.com/w3c/wcag21/issues/792<br />
<br />
Reviewers: Charles Adams<br />
<br />
=== Understanding Orientation ===<br />
https://github.com/w3c/wcag21/issues/793<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Motion Actuation ===<br />
https://github.com/w3c/wcag21/issues/794<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Status Changes ===<br />
https://github.com/w3c/wcag21/issues/795<br />
<br />
Reviewers: Bruce Bailey (done 4/17), David MacDonald, SteveRep<br />
<br />
David says: I've reviewed the document, made a few editorial changes while not changing the substance. The current Branch[https://github.com/w3c/wcag21/tree/status-changes "Status-Changes"] was in conflict with the Master, so after completing edits I created a new branch [https://github.com/w3c/wcag21/tree/status-messages "status-messages"] and copied the status-message file over there. I've made a [https://github.com/w3c/wcag21/pull/872 pull request #872]</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-understanding-documents&diff=9694Wcag21-understanding-documents2018-04-21T16:40:43Z<p>Dmacdona: /* Understanding Status Changes */</p>
<hr />
<div>The AGWG need to review and update the new understanding documents for WCAG 2.1<br />
<br />
The survey for approval will be used towards the end of the process, in the meantime, please put yourself down for reviewing one or more docs. [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Directions from Alastair's email]: <br />
<br />
<blockquote><br />
The basics to cover are:<br />
<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]<br />
* Does it provide understanding of the SC! (It is especially helpful if you sign up for one you’re less familiar with.)<br />
* Are there errors or phrasing issues (editorial);<br />
* Does it list enough techniques? (Techniques will be the next step, we don’t expect them to exist yet, but we should know what they are.)<br />
<br />
Follow the link to add comments in the main github thread.<br />
<br />
If you are confident with github please do make the updates to the doc directly. If they are significant edits (e.g. adding/removing sections) please create a branch off from the understanding-doc branch and then submit a merge request. (Email the chairs if you’d like help with that.)<br />
<br />
Otherwise, comments in github with suggested updates are good, as are documents attached with track changes / comments.<br />
<br />
</blockquote><br />
<br />
For editorial questions please refer to the [https://www.w3.org/WAI/PF/editors/style_editorial PF editors style guide].<br />
<br />
== List of understanding docs ==<br />
<br />
=== Understanding Identify Common Purpose ===<br />
https://github.com/w3c/wcag21/issues/779<br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Identify Purpose ===<br />
https://github.com/w3c/wcag21/issues/780 <br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Reflow ===<br />
https://github.com/w3c/wcag21/issues/781<br />
<br />
Reviewers: Jake Abma, Jim Allan<br />
<br />
=== Understanding Non-text Contrast ===<br />
https://github.com/w3c/wcag21/issues/782<br />
<br />
Reviewers: Mike Elledge, Mike Gower<br />
<br />
=== Understanding Text Spacing ===<br />
https://github.com/w3c/wcag21/issues/783<br />
<br />
Reviewer: Laura Carlson (Done April 18, 2018)<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]: Yes<br />
* Does it provide understanding of the SC?: Yes<br />
* Are there errors or phrasing issues (editorial)?: None that I detected.<br />
* Does it list enough techniques? I think so.<br />
<br />
Reviewer: E.A. Draffan<br />
<br />
=== Understanding Content on Hover or Focus ===<br />
https://github.com/w3c/wcag21/issues/784<br />
<br />
Reviewers: Mike Gower (completed), SteveRep<br />
<br />
=== Understanding Timeouts ===<br />
https://github.com/w3c/wcag21/issues/785<br />
<br />
Reviewers: John Kirwood<br />
<br />
=== Understanding Animation from Interactions ===<br />
https://github.com/w3c/wcag21/issues/786<br />
<br />
Reviewers: Glenda Sims (1st pass done, creating pull request next)<br />
<br />
=== Understanding Character Key Shortcuts ===<br />
https://github.com/w3c/wcag21/issues/787<br />
<br />
Reviewers: David MacD<br />
I've completed the review and made a [https://github.com/w3c/wcag21/pull/870 pull request]<br />
<br />
=== Understanding Label in Name ===<br />
https://github.com/w3c/wcag21/issues/788<br />
<br />
Reviewers: Marc Johlic<br />
<br />
=== Understanding Target Size ===<br />
https://github.com/w3c/wcag21/issues/789<br />
<br />
Reviewers: Jake Abma<br />
<br />
=== Understanding Pointer Gestures ===<br />
https://github.com/w3c/wcag21/issues/790<br />
<br />
Reviewers: Greg Lowney.<br />
<br />
=== Understanding Pointer Cancellation ===<br />
https://github.com/w3c/wcag21/issues/791<br />
<br />
Reviewers: SteveRep<br />
<br />
=== Understanding Concurrent Input Mechanisms ===<br />
https://github.com/w3c/wcag21/issues/792<br />
<br />
Reviewers: Charles Adams<br />
<br />
=== Understanding Orientation ===<br />
https://github.com/w3c/wcag21/issues/793<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Motion Actuation ===<br />
https://github.com/w3c/wcag21/issues/794<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Status Changes ===<br />
https://github.com/w3c/wcag21/issues/795<br />
<br />
Reviewers: Bruce Bailey (done 4/17), David MacDonald, SteveRep<br />
<br />
David says: I've reviewed the document, made a few editorial changes while not changing the substance. The current Branch[https://github.com/w3c/wcag21/tree/status-changes "Status-Changes"] <br />
<br />
<br />
was in conflict with the Master, so after completing edits I created a new branch [https://github.com/w3c/wcag21/tree/status-messages "status-messages"] and copied the status-message file over there.<br />
<br />
<br />
I've made a [https://github.com/w3c/wcag21/pull/872 pull request #872]</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-understanding-documents&diff=9693Wcag21-understanding-documents2018-04-21T16:39:41Z<p>Dmacdona: /* Understanding Character Key Shortcuts */</p>
<hr />
<div>The AGWG need to review and update the new understanding documents for WCAG 2.1<br />
<br />
The survey for approval will be used towards the end of the process, in the meantime, please put yourself down for reviewing one or more docs. [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Directions from Alastair's email]: <br />
<br />
<blockquote><br />
The basics to cover are:<br />
<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]<br />
* Does it provide understanding of the SC! (It is especially helpful if you sign up for one you’re less familiar with.)<br />
* Are there errors or phrasing issues (editorial);<br />
* Does it list enough techniques? (Techniques will be the next step, we don’t expect them to exist yet, but we should know what they are.)<br />
<br />
Follow the link to add comments in the main github thread.<br />
<br />
If you are confident with github please do make the updates to the doc directly. If they are significant edits (e.g. adding/removing sections) please create a branch off from the understanding-doc branch and then submit a merge request. (Email the chairs if you’d like help with that.)<br />
<br />
Otherwise, comments in github with suggested updates are good, as are documents attached with track changes / comments.<br />
<br />
</blockquote><br />
<br />
For editorial questions please refer to the [https://www.w3.org/WAI/PF/editors/style_editorial PF editors style guide].<br />
<br />
== List of understanding docs ==<br />
<br />
=== Understanding Identify Common Purpose ===<br />
https://github.com/w3c/wcag21/issues/779<br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Identify Purpose ===<br />
https://github.com/w3c/wcag21/issues/780 <br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Reflow ===<br />
https://github.com/w3c/wcag21/issues/781<br />
<br />
Reviewers: Jake Abma, Jim Allan<br />
<br />
=== Understanding Non-text Contrast ===<br />
https://github.com/w3c/wcag21/issues/782<br />
<br />
Reviewers: Mike Elledge, Mike Gower<br />
<br />
=== Understanding Text Spacing ===<br />
https://github.com/w3c/wcag21/issues/783<br />
<br />
Reviewer: Laura Carlson (Done April 18, 2018)<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]: Yes<br />
* Does it provide understanding of the SC?: Yes<br />
* Are there errors or phrasing issues (editorial)?: None that I detected.<br />
* Does it list enough techniques? I think so.<br />
<br />
Reviewer: E.A. Draffan<br />
<br />
=== Understanding Content on Hover or Focus ===<br />
https://github.com/w3c/wcag21/issues/784<br />
<br />
Reviewers: Mike Gower (completed), SteveRep<br />
<br />
=== Understanding Timeouts ===<br />
https://github.com/w3c/wcag21/issues/785<br />
<br />
Reviewers: John Kirwood<br />
<br />
=== Understanding Animation from Interactions ===<br />
https://github.com/w3c/wcag21/issues/786<br />
<br />
Reviewers: Glenda Sims (1st pass done, creating pull request next)<br />
<br />
=== Understanding Character Key Shortcuts ===<br />
https://github.com/w3c/wcag21/issues/787<br />
<br />
Reviewers: David MacD<br />
I've completed the review and made a [https://github.com/w3c/wcag21/pull/870 pull request]<br />
<br />
=== Understanding Label in Name ===<br />
https://github.com/w3c/wcag21/issues/788<br />
<br />
Reviewers: Marc Johlic<br />
<br />
=== Understanding Target Size ===<br />
https://github.com/w3c/wcag21/issues/789<br />
<br />
Reviewers: Jake Abma<br />
<br />
=== Understanding Pointer Gestures ===<br />
https://github.com/w3c/wcag21/issues/790<br />
<br />
Reviewers: Greg Lowney.<br />
<br />
=== Understanding Pointer Cancellation ===<br />
https://github.com/w3c/wcag21/issues/791<br />
<br />
Reviewers: SteveRep<br />
<br />
=== Understanding Concurrent Input Mechanisms ===<br />
https://github.com/w3c/wcag21/issues/792<br />
<br />
Reviewers: Charles Adams<br />
<br />
=== Understanding Orientation ===<br />
https://github.com/w3c/wcag21/issues/793<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Motion Actuation ===<br />
https://github.com/w3c/wcag21/issues/794<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Status Changes ===<br />
https://github.com/w3c/wcag21/issues/795<br />
<br />
Reviewers: Bruce Bailey (done 4/17), David MacDonald, SteveRep<br />
<br />
David says: I've reviewed the document, made a few editorial changes while not changing the substance. The current Branch "Status-Changes" <br />
https://github.com/w3c/wcag21/tree/status-changes<br />
<br />
was in conflict with the Master, so after completing edits I created a new branch "status-messages" and copied the status-message file over there.<br />
https://github.com/w3c/wcag21/tree/status-messages<br />
<br />
I've made a pull request<br />
https://github.com/w3c/wcag21/pull/872</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-understanding-documents&diff=9692Wcag21-understanding-documents2018-04-21T16:39:16Z<p>Dmacdona: /* Understanding Character Key Shortcuts */</p>
<hr />
<div>The AGWG need to review and update the new understanding documents for WCAG 2.1<br />
<br />
The survey for approval will be used towards the end of the process, in the meantime, please put yourself down for reviewing one or more docs. [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Directions from Alastair's email]: <br />
<br />
<blockquote><br />
The basics to cover are:<br />
<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]<br />
* Does it provide understanding of the SC! (It is especially helpful if you sign up for one you’re less familiar with.)<br />
* Are there errors or phrasing issues (editorial);<br />
* Does it list enough techniques? (Techniques will be the next step, we don’t expect them to exist yet, but we should know what they are.)<br />
<br />
Follow the link to add comments in the main github thread.<br />
<br />
If you are confident with github please do make the updates to the doc directly. If they are significant edits (e.g. adding/removing sections) please create a branch off from the understanding-doc branch and then submit a merge request. (Email the chairs if you’d like help with that.)<br />
<br />
Otherwise, comments in github with suggested updates are good, as are documents attached with track changes / comments.<br />
<br />
</blockquote><br />
<br />
For editorial questions please refer to the [https://www.w3.org/WAI/PF/editors/style_editorial PF editors style guide].<br />
<br />
== List of understanding docs ==<br />
<br />
=== Understanding Identify Common Purpose ===<br />
https://github.com/w3c/wcag21/issues/779<br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Identify Purpose ===<br />
https://github.com/w3c/wcag21/issues/780 <br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Reflow ===<br />
https://github.com/w3c/wcag21/issues/781<br />
<br />
Reviewers: Jake Abma, Jim Allan<br />
<br />
=== Understanding Non-text Contrast ===<br />
https://github.com/w3c/wcag21/issues/782<br />
<br />
Reviewers: Mike Elledge, Mike Gower<br />
<br />
=== Understanding Text Spacing ===<br />
https://github.com/w3c/wcag21/issues/783<br />
<br />
Reviewer: Laura Carlson (Done April 18, 2018)<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]: Yes<br />
* Does it provide understanding of the SC?: Yes<br />
* Are there errors or phrasing issues (editorial)?: None that I detected.<br />
* Does it list enough techniques? I think so.<br />
<br />
Reviewer: E.A. Draffan<br />
<br />
=== Understanding Content on Hover or Focus ===<br />
https://github.com/w3c/wcag21/issues/784<br />
<br />
Reviewers: Mike Gower (completed), SteveRep<br />
<br />
=== Understanding Timeouts ===<br />
https://github.com/w3c/wcag21/issues/785<br />
<br />
Reviewers: John Kirwood<br />
<br />
=== Understanding Animation from Interactions ===<br />
https://github.com/w3c/wcag21/issues/786<br />
<br />
Reviewers: Glenda Sims (1st pass done, creating pull request next)<br />
<br />
=== Understanding Character Key Shortcuts ===<br />
https://github.com/w3c/wcag21/issues/787<br />
<br />
Reviewers: David MacD<br />
I've completed the review and made a pull [request https://github.com/w3c/wcag21/pull/870]<br />
<br />
=== Understanding Label in Name ===<br />
https://github.com/w3c/wcag21/issues/788<br />
<br />
Reviewers: Marc Johlic<br />
<br />
=== Understanding Target Size ===<br />
https://github.com/w3c/wcag21/issues/789<br />
<br />
Reviewers: Jake Abma<br />
<br />
=== Understanding Pointer Gestures ===<br />
https://github.com/w3c/wcag21/issues/790<br />
<br />
Reviewers: Greg Lowney.<br />
<br />
=== Understanding Pointer Cancellation ===<br />
https://github.com/w3c/wcag21/issues/791<br />
<br />
Reviewers: SteveRep<br />
<br />
=== Understanding Concurrent Input Mechanisms ===<br />
https://github.com/w3c/wcag21/issues/792<br />
<br />
Reviewers: Charles Adams<br />
<br />
=== Understanding Orientation ===<br />
https://github.com/w3c/wcag21/issues/793<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Motion Actuation ===<br />
https://github.com/w3c/wcag21/issues/794<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Status Changes ===<br />
https://github.com/w3c/wcag21/issues/795<br />
<br />
Reviewers: Bruce Bailey (done 4/17), David MacDonald, SteveRep<br />
<br />
David says: I've reviewed the document, made a few editorial changes while not changing the substance. The current Branch "Status-Changes" <br />
https://github.com/w3c/wcag21/tree/status-changes<br />
<br />
was in conflict with the Master, so after completing edits I created a new branch "status-messages" and copied the status-message file over there.<br />
https://github.com/w3c/wcag21/tree/status-messages<br />
<br />
I've made a pull request<br />
https://github.com/w3c/wcag21/pull/872</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-understanding-documents&diff=9691Wcag21-understanding-documents2018-04-21T16:37:41Z<p>Dmacdona: /* Understanding Status Changes */</p>
<hr />
<div>The AGWG need to review and update the new understanding documents for WCAG 2.1<br />
<br />
The survey for approval will be used towards the end of the process, in the meantime, please put yourself down for reviewing one or more docs. [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Directions from Alastair's email]: <br />
<br />
<blockquote><br />
The basics to cover are:<br />
<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]<br />
* Does it provide understanding of the SC! (It is especially helpful if you sign up for one you’re less familiar with.)<br />
* Are there errors or phrasing issues (editorial);<br />
* Does it list enough techniques? (Techniques will be the next step, we don’t expect them to exist yet, but we should know what they are.)<br />
<br />
Follow the link to add comments in the main github thread.<br />
<br />
If you are confident with github please do make the updates to the doc directly. If they are significant edits (e.g. adding/removing sections) please create a branch off from the understanding-doc branch and then submit a merge request. (Email the chairs if you’d like help with that.)<br />
<br />
Otherwise, comments in github with suggested updates are good, as are documents attached with track changes / comments.<br />
<br />
</blockquote><br />
<br />
For editorial questions please refer to the [https://www.w3.org/WAI/PF/editors/style_editorial PF editors style guide].<br />
<br />
== List of understanding docs ==<br />
<br />
=== Understanding Identify Common Purpose ===<br />
https://github.com/w3c/wcag21/issues/779<br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Identify Purpose ===<br />
https://github.com/w3c/wcag21/issues/780 <br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Reflow ===<br />
https://github.com/w3c/wcag21/issues/781<br />
<br />
Reviewers: Jake Abma, Jim Allan<br />
<br />
=== Understanding Non-text Contrast ===<br />
https://github.com/w3c/wcag21/issues/782<br />
<br />
Reviewers: Mike Elledge, Mike Gower<br />
<br />
=== Understanding Text Spacing ===<br />
https://github.com/w3c/wcag21/issues/783<br />
<br />
Reviewer: Laura Carlson (Done April 18, 2018)<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]: Yes<br />
* Does it provide understanding of the SC?: Yes<br />
* Are there errors or phrasing issues (editorial)?: None that I detected.<br />
* Does it list enough techniques? I think so.<br />
<br />
Reviewer: E.A. Draffan<br />
<br />
=== Understanding Content on Hover or Focus ===<br />
https://github.com/w3c/wcag21/issues/784<br />
<br />
Reviewers: Mike Gower (completed), SteveRep<br />
<br />
=== Understanding Timeouts ===<br />
https://github.com/w3c/wcag21/issues/785<br />
<br />
Reviewers: John Kirwood<br />
<br />
=== Understanding Animation from Interactions ===<br />
https://github.com/w3c/wcag21/issues/786<br />
<br />
Reviewers: Glenda Sims (1st pass done, creating pull request next)<br />
<br />
=== Understanding Character Key Shortcuts ===<br />
https://github.com/w3c/wcag21/issues/787<br />
<br />
Reviewers: David MacD<br />
<br />
=== Understanding Label in Name ===<br />
https://github.com/w3c/wcag21/issues/788<br />
<br />
Reviewers: Marc Johlic<br />
<br />
=== Understanding Target Size ===<br />
https://github.com/w3c/wcag21/issues/789<br />
<br />
Reviewers: Jake Abma<br />
<br />
=== Understanding Pointer Gestures ===<br />
https://github.com/w3c/wcag21/issues/790<br />
<br />
Reviewers: Greg Lowney.<br />
<br />
=== Understanding Pointer Cancellation ===<br />
https://github.com/w3c/wcag21/issues/791<br />
<br />
Reviewers: SteveRep<br />
<br />
=== Understanding Concurrent Input Mechanisms ===<br />
https://github.com/w3c/wcag21/issues/792<br />
<br />
Reviewers: Charles Adams<br />
<br />
=== Understanding Orientation ===<br />
https://github.com/w3c/wcag21/issues/793<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Motion Actuation ===<br />
https://github.com/w3c/wcag21/issues/794<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Status Changes ===<br />
https://github.com/w3c/wcag21/issues/795<br />
<br />
Reviewers: Bruce Bailey (done 4/17), David MacDonald, SteveRep<br />
<br />
David says: I've reviewed the document, made a few editorial changes while not changing the substance. The current Branch "Status-Changes" <br />
https://github.com/w3c/wcag21/tree/status-changes<br />
<br />
was in conflict with the Master, so after completing edits I created a new branch "status-messages" and copied the status-message file over there.<br />
https://github.com/w3c/wcag21/tree/status-messages<br />
<br />
I've made a pull request<br />
https://github.com/w3c/wcag21/pull/872</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-understanding-documents&diff=9690Wcag21-understanding-documents2018-04-21T16:36:43Z<p>Dmacdona: /* Understanding Status Changes */</p>
<hr />
<div>The AGWG need to review and update the new understanding documents for WCAG 2.1<br />
<br />
The survey for approval will be used towards the end of the process, in the meantime, please put yourself down for reviewing one or more docs. [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Directions from Alastair's email]: <br />
<br />
<blockquote><br />
The basics to cover are:<br />
<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]<br />
* Does it provide understanding of the SC! (It is especially helpful if you sign up for one you’re less familiar with.)<br />
* Are there errors or phrasing issues (editorial);<br />
* Does it list enough techniques? (Techniques will be the next step, we don’t expect them to exist yet, but we should know what they are.)<br />
<br />
Follow the link to add comments in the main github thread.<br />
<br />
If you are confident with github please do make the updates to the doc directly. If they are significant edits (e.g. adding/removing sections) please create a branch off from the understanding-doc branch and then submit a merge request. (Email the chairs if you’d like help with that.)<br />
<br />
Otherwise, comments in github with suggested updates are good, as are documents attached with track changes / comments.<br />
<br />
</blockquote><br />
<br />
For editorial questions please refer to the [https://www.w3.org/WAI/PF/editors/style_editorial PF editors style guide].<br />
<br />
== List of understanding docs ==<br />
<br />
=== Understanding Identify Common Purpose ===<br />
https://github.com/w3c/wcag21/issues/779<br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Identify Purpose ===<br />
https://github.com/w3c/wcag21/issues/780 <br />
<br />
Reviewers: JF<br />
<br />
=== Understanding Reflow ===<br />
https://github.com/w3c/wcag21/issues/781<br />
<br />
Reviewers: Jake Abma, Jim Allan<br />
<br />
=== Understanding Non-text Contrast ===<br />
https://github.com/w3c/wcag21/issues/782<br />
<br />
Reviewers: Mike Elledge, Mike Gower<br />
<br />
=== Understanding Text Spacing ===<br />
https://github.com/w3c/wcag21/issues/783<br />
<br />
Reviewer: Laura Carlson (Done April 18, 2018)<br />
* [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018AprJun/0357.html Does it include the things it should?]: Yes<br />
* Does it provide understanding of the SC?: Yes<br />
* Are there errors or phrasing issues (editorial)?: None that I detected.<br />
* Does it list enough techniques? I think so.<br />
<br />
Reviewer: E.A. Draffan<br />
<br />
=== Understanding Content on Hover or Focus ===<br />
https://github.com/w3c/wcag21/issues/784<br />
<br />
Reviewers: Mike Gower (completed), SteveRep<br />
<br />
=== Understanding Timeouts ===<br />
https://github.com/w3c/wcag21/issues/785<br />
<br />
Reviewers: John Kirwood<br />
<br />
=== Understanding Animation from Interactions ===<br />
https://github.com/w3c/wcag21/issues/786<br />
<br />
Reviewers: Glenda Sims (1st pass done, creating pull request next)<br />
<br />
=== Understanding Character Key Shortcuts ===<br />
https://github.com/w3c/wcag21/issues/787<br />
<br />
Reviewers: David MacD<br />
<br />
=== Understanding Label in Name ===<br />
https://github.com/w3c/wcag21/issues/788<br />
<br />
Reviewers: Marc Johlic<br />
<br />
=== Understanding Target Size ===<br />
https://github.com/w3c/wcag21/issues/789<br />
<br />
Reviewers: Jake Abma<br />
<br />
=== Understanding Pointer Gestures ===<br />
https://github.com/w3c/wcag21/issues/790<br />
<br />
Reviewers: Greg Lowney.<br />
<br />
=== Understanding Pointer Cancellation ===<br />
https://github.com/w3c/wcag21/issues/791<br />
<br />
Reviewers: SteveRep<br />
<br />
=== Understanding Concurrent Input Mechanisms ===<br />
https://github.com/w3c/wcag21/issues/792<br />
<br />
Reviewers: Charles Adams<br />
<br />
=== Understanding Orientation ===<br />
https://github.com/w3c/wcag21/issues/793<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Motion Actuation ===<br />
https://github.com/w3c/wcag21/issues/794<br />
<br />
Reviewers: Bruce Bailey (done 4/19)<br />
<br />
=== Understanding Status Changes ===<br />
https://github.com/w3c/wcag21/issues/795<br />
<br />
Reviewers: Bruce Bailey (done 4/17), David MacDonald, SteveRep<br />
<br />
David says: I've reviewed the document, made a few editorial changes while not changing the substance. The current Branch "Status-Changes" <br />
https://github.com/w3c/wcag21/tree/status-changes<br />
was in conflict with the Master, so after completing edits I created a new branch "status-messages" and copied the status-message file over there.<br />
https://github.com/w3c/wcag21/tree/status-messages</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Wcag21-understanding-documents&diff=9664Wcag21-understanding-documents2018-04-17T16:26:46Z<p>Dmacdona: /* Understanding Status Changes */</p>
<hr />
<div>The AGWG need to review and update the new understanding documents for WCAG 2.1<br />
<br />
The survey for approval will be used towards the end of the process, in the meantime, please put yourself down for reviewing one or more docs:<br />
<br />
== List of understanding docs ==<br />
<br />
<br />
=== Understanding Identify Common Purpose ===<br />
https://github.com/w3c/wcag21/issues/779<br />
<br />
Reviewers: <br />
<br />
=== Understanding Identify Purpose ===<br />
https://github.com/w3c/wcag21/issues/780 <br />
<br />
Reviewers: <br />
<br />
=== Understanding Reflow ===<br />
https://github.com/w3c/wcag21/issues/781<br />
<br />
Reviewers: Jake Abma, Jim Allan<br />
<br />
=== Understanding Non-text Contrast ===<br />
https://github.com/w3c/wcag21/issues/782<br />
<br />
Reviewers: <br />
<br />
=== Understanding Text Spacing ===<br />
https://github.com/w3c/wcag21/issues/783<br />
<br />
Reviewers: Laura Carlson<br />
<br />
=== Understanding Content on Hover or Focus ===<br />
https://github.com/w3c/wcag21/issues/784<br />
<br />
Reviewers: Mike Gower<br />
<br />
=== Understanding Timeouts ===<br />
https://github.com/w3c/wcag21/issues/785<br />
<br />
Reviewers: <br />
<br />
=== Understanding Animation from Interactions ===<br />
https://github.com/w3c/wcag21/issues/786<br />
<br />
Reviewers: Glenda Sims (volunteers)<br />
<br />
=== Understanding Character Key Shortcuts ===<br />
https://github.com/w3c/wcag21/issues/787<br />
<br />
Reviewers: <br />
<br />
=== Understanding Label in Name ===<br />
https://github.com/w3c/wcag21/issues/788<br />
<br />
Reviewers: <br />
<br />
=== Understanding Target Size ===<br />
https://github.com/w3c/wcag21/issues/789<br />
<br />
Reviewers: Jake Abma<br />
<br />
=== Understanding Pointer Gestures ===<br />
https://github.com/w3c/wcag21/issues/790<br />
<br />
Reviewers: <br />
<br />
=== Understanding Pointer Cancellation ===<br />
https://github.com/w3c/wcag21/issues/791<br />
<br />
Reviewers: <br />
<br />
=== Understanding Concurrent Input Mechanisms ===<br />
https://github.com/w3c/wcag21/issues/792<br />
<br />
Reviewers: Charles Adams<br />
<br />
=== Understanding Orientation ===<br />
https://github.com/w3c/wcag21/issues/793<br />
<br />
Reviewers: <br />
<br />
=== Understanding Motion Actuation ===<br />
https://github.com/w3c/wcag21/issues/794<br />
<br />
Reviewers: <br />
<br />
=== Understanding Status Changes ===<br />
https://github.com/w3c/wcag21/issues/795<br />
<br />
Reviewers: Bruce Bailey<br />
David MacDonald</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1_Implementations&diff=9406WCAG 2.1 Implementations2018-02-13T17:57:02Z<p>Dmacdona: /* 3.2.6 Status Changes */</p>
<hr />
<div>Until the resource for implementation information is available, this page will collect information about implementations.<br />
<br />
==Exit Criteria:==<br />
https://www.w3.org/TR/WCAG21/#exit-criteria<br />
<br />
==Full Site Conformance==<br />
Sites demonstrating conformance to WCAG 2.1:<br />
===At AA (8 needed):===<br />
# Knowbilty wants to make their knowability.org WCAG 2.1 compliant. Glenda spoke to Sharron, Eric Eggert & Robert Jolly. So, assuming their redesign stays on schedule and they don't hit any major glitches with WCAG 2.1 compliance...knowbility.org will be a WCAG 2.1 A/AA implementation example!<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
#<br />
<br />
===At AAA (2 needed): ===<br />
# lflegal.com (expressed interest)<br />
# <br />
# <br />
#<br />
<br />
==Individual SC Implementations==<br />
===Level A===<br />
====2.4.11 Character Key Shortcuts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Gmail (character-key shortcuts are not alternate controls, but can be changed by the user)<br />
* WordPress (character-key shortcuts for comments are alternate controls that can be switched off by the user)<br />
* [https://www.youtube.com/watch?v=xzSyIA4OWYE Single character key shortcuts adversely affecting speech input – example 1 Gdocs]<br />
* [https://www.youtube.com/watch?v=OPjfpDU9S08 Single character key shortcuts adversely affecting speech input – example 2 Twitter]<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.4.12 Label in Name====<br />
Sites demonstrating successful implementation of this SC:<br />
* Jake will find 2-3 example sites - Mike Gower can confirm<br />
* David MacDonald says Google home page is excellent passing example<br />
<br />
'''PASS'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
www.Google.com search field. Visible label is the button "Google Search" and ACCNAME is aria-label="Search"<br />
<br />
<br />
TEXT<br />
<br />
* http://www.bbc.com/ => all links in top menu and in doormat match<br />
* https://www.nytimes.com/ => all links in top menu and in doormat match<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.microsoft.com/en-us => Logo top left has name "Microsoft"<br />
* https://www.netflix.com/ => Logo top left has name "Netflix"<br />
* https://www.uber.com/en-NL/ => Below doormat the 3 app stores logo's have a title attribute with same text (except the Apple one, it has one word different)<br />
<br />
'''Accessible starts with Visible. The accessible name begins with the visible label.'''<br />
<br />
TEXT<br />
<br />
* https://www.google.com => when opening top right menu (3x3 squares), on bottom is "More" link and name is "More Google apps"<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.deque.com/ => The 'banner links' with "More information here" and "Get the free Download" start with visible text supplemented with additional info<br />
<br />
'''FAIL'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
<br />
TEXT<br />
<br />
* https://www.wikipedia.org => Search field has language dropdown with text "EN" but has name "English" (or other language when selected)<br />
<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://edition.cnn.com => CNN logo top left without alt text, url is read and CNN is part of URL but this is not official for the calculation<br />
* https://edition.cnn.com => CNN doormat links (Money, entertainment, tech, travel etc.) without alt text, url is read and text is part of URL but this is not official for the calculation<br />
* https://en.wikipedia.org/wiki/Main_Page => Logo top left has text "Wikipedia The Free Encyclopedia" but name "Visit the main page". <br />
* https://en.wikipedia.org/wiki/Main_Page => bottom right logo/text "a wikimedia project", with name "Wikimedia foundation"<br />
* https://www.telegraaf.nl/ => Text logo's at bottom for other section of the site have no name, URL is being read<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.1 Pointer Gestures====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/O7hibkNRTxk indiatimes.com (video of interaction on iPhone)]. The India times.com start page (8. February 2018) has a horizontal slider which can be moved with a one-finger swipe gesture. There are arrow buttons to the left and right of the slider which allow advancing the content with a single finger tap. So this would pass SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/TmEsQkJcpgk Ebay.com Start Page (video of interaction on Android smartphone)]. The Ebay start page (8. February 2018) has a content slider which can be moved with a one finger swipe gesture. There is alternative in one arrow button on top of the slider which leads to another page which has the same content as a slider. Arguably, this would pass SC 2.5.1 Pointer Gestures since a single finger tap accesses an equivalent alternative.<br />
# [https://youtu.be/s13KtPgqQBw Walmart.com start page (video of interaction on Android Smartphone)]. The Walmart homepage (8.February 2018) has a horizontal slider which can be moved with a one finger gesture. There are dots below the slider which allow setting the position of the slider through a single finger tap, So the would pass SC 2.5.1 Pointer Gestures.<br />
<br />
Sites demonstrating a failure of meeting this SC:<br />
# [https://youtu.be/vwnV5CAVtVA Guardian.co.uk start page (video of trackpad interaction on MacBook pro)]. The Guardian homepage (8. February 2018) has a slider element with videos which can be moved with a two-finger swipe gesture on the trackpad (MacBook pro OS X 10.11.6) (one-finger swipe on iPhone with iOS 11 ) There is no alternative to move the slider content so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/KYIX0e9uYBg Drag-and-Drop example (video of interaction on iPhone)]. The [http://marcojakob.github.io/dart-dnd/basic/web/ Drag-and-drop example by Marco Jacob] (recorded 8. February 2018) shows how file icons are dragged to a waste basket to delete the files. There is no single tap alternative for deletion, so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/SbyHxdXkgew North2.net Drag-and-drop (video of interaction] In the section "About us", the design agency north2.net (9. February 2018) uses drag-and-drop to select members of staff (video shows desktop interaction in Windows / Firefox - the drag-and-drop functionality is not presented on a smartphone). On the desktop, there seems to be no other way to select staff so this would fail SC 2.5.1 Pointer Gestures.<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.2 Pointer Cancellation====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* https://wet-boew.github.io/v4.0-ci/demos/formvalid/formvalid-en.html<br />
Submit form does not activate on the down event, the View Code disclosures are on the up event.<br />
* https://signup.com/<br />
"Start planning" button activates on the up event.<br />
<br />
Techniques proposed:<br />
* Using standard HTML buttons and links. (All standard interactive elements in HTML are on the up event.<br />
* Using JavaScript "onkeyup" and "onmouseup" attributes to activate controls.<br />
<br />
====2.6.1 Motion Actuation====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/KBqI4YXDH18 Web form pasting, Shake-to-undo (video of interaction on iPhone)]. After pasting an account number into the text input field of a library web app ([http://buecherhallen.de buecherhallen.de], 9. February 2018), shaking the iPhone brings up a dialog to confirm or cancel the undo action. ‘Shake to undo’ input can be disabled in the OS settings, so this would meet SC 2.6.1 Motion Actuation.<br />
<br />
Sites demonstrating failure of conforming to this SC:<br />
# [https://youtu.be/b0AIR17Xz2g Regnskogfondet move-device-to-pan (video of interaction)]. The site [http://rainforest.arkivert.no/ rainforest.arkivert.no] (9. February 2018) pans an interactive panorama when the user moves the device in a 360 degrees circle. There is no other way to pan the panorama to reach the embedded circular image links, so this would fail SC 2.6.1 Motion Actuation.<br />
<br />
*Kathy will check notes<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
===Level AA===<br />
<br />
==== 1.3.4 Identify Common Purpose ====<br />
Sites demonstrating successful implementation of this SC:<br />
* John Foliot will look<br />
* <br />
<br />
Techniques proposed:<br />
* <br />
<br />
====1.4.10 Reflow====<br />
Sites demonstrating successful implementation of this SC:<br />
* Texas School for the Blind and Visually Impaired [https://www.tsbvi.edu www.tsbvi.edu] - zoom page or hit Mobile button at top right of content<br />
* other<br />
<br />
Techniques proposed:<br />
* Using media queries (CSS). Ref: [http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ em based media queries] AND<br />
* @@ New: Using CSS grids to reflow content (CSS). Ref: [http://alistapart.com/article/fluidgrids fluid grids] OR<br />
* @@ New: [https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Using CSS Flexbox to reflow content (CSS)] OR<br />
* [https://www.w3.org/TR/WCAG20-TECHS/SCR34 SCR34: Calculating size and position in a way that scales with text size (Scripting)]<br />
* [https://www.w3.org/TR/WCAG20-TECHS/G206 G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text]<br />
<br />
====1.4.11 Non-Text Contrast====<br />
Sites demonstrating successful implementation of this SC:<br />
Glenda volunteered to find examples<br />
# State Farm https://www.statefarm.com/ <br />
## Graphical Objects - icons <br />
## Visual Focus Indicators <br />
# Accessibility at Penn State | Charts & Accessibility - http://accessibility.psu.edu/images/charts/ <br />
## Graphical Objects - charts/graphs <br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====1.4.12 Text Spacing====<br />
Sites demonstrating successful implementation of this SC:<br />
* [https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78 Results of Bookmarklet Tests for Issue 78] - Alastair Campbell, Amani Ali, Glenda Sims, Laura Carlson (67 pages were tested between July 25 and August 3, 2017)<br />
* [https://github.com/w3c/wcag21/issues/677#issuecomment-358043678 3 possible Japanese pages] - Makoto<br />
<br />
Techniques proposed:<br />
* [https://www.w3.org/WAI/GL/wiki/Allowing_for_Spacing_Override Allowing for Spacing Override (Draft)]<br />
<br />
====1.4.13 Content on Hover or Focus====<br />
Sites demonstrating successful implementation of this SC:<br />
* Steve R<br />
<br />
Techniques proposed:<br />
* ARIA: Using role="tooltip"<br />
* CSS: Using hover and focus pseudo classes<br />
<br />
====2.6.2 Orientation====<br />
Sites demonstrating successful implementation of this SC:<br />
* Marc Johlic<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====3.2.6 Status Changes====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* https://www.benefitcosmetics.com/us/en#<br />
Shopping Bag status message is a number beside the shopping bag. JAWS announces the number of items as it changes.<br />
<br />
* https://www.oct.ca/<br />
Search input on the home page (top right)<br />
Type in a keyword and press Enter. Screen reader announces "Searched for [term]. Your search returned x results."<br />
<br />
Techniques proposed:<br />
* Using aria-live regions to announce status messages to screen readers.<br />
* Using aria-live region roles to announce status messages to screen readers.<br />
<br />
===Level AAA===<br />
==== 1.3.5 Identify Purpose====<br />
Sites demonstrating successful implementation of this SC:<br />
* Lisa<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.6 Timeouts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Need to review how we tested this in 2.0<br />
* Airline booking sites?<br />
* Mike Gower<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.7 Animation from Interactions====<br />
<br />
Definitely failing examples:<br />
* [https://www.nytimes.com/interactive/2016/09/30/opinion/penn-station-reborn.html?_r=1 NYT Penn startion article]<br />
* [http://taotajima.jp/works/waxing-moon/ http://taotajima.jp/works/waxing-moon/] WARNING! Immediate severe vestibular trigger warning.<br />
<br />
Sites demonstrating successful implementation of this SC:<br />
<br />
1. On the [https://www.apple.com/iphone/photography-how-to/ iPhone photography how-to] page, it changes if you have the reduced-motion preference set (Safari on OSX/iOS). <br />
* Video does not play automatically.<br />
* The changes on mouse-over take place (an image appears), but the background image does not zoom in gradually.<br />
<br />
2. On the [https://www.apple.com/environment/ Apple Environment page] the tilting solar panels animation (triggered by scrolling) does not take place with the reduce-motion preference turned on. NB: The green sun is still animated, but that is an in-place animation, not triggered by interaction. Several other animations are also stopped, including the packaging and materials panels.<br />
<br />
Techniques proposed:<br />
* Using the reduced motion preference to prevent animation triggered by scrolling or other interactions.<br />
* Button to turn off animations triggered by scrolling.<br />
<br />
====2.5.3 Target Size====<br />
Sites demonstrating successful implementation of this SC:<br />
* Codepen https://codepen.io/<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.4 Concurrent Input Mechanisms====<br />
Sites demonstrating successful implementation of this SC:<br />
* Sway sites?<br />
* Chuck<br />
<br />
Techniques proposed:<br />
*<br />
*</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1_Implementations&diff=9405WCAG 2.1 Implementations2018-02-13T17:56:34Z<p>Dmacdona: /* 3.2.6 Status Changes */</p>
<hr />
<div>Until the resource for implementation information is available, this page will collect information about implementations.<br />
<br />
==Exit Criteria:==<br />
https://www.w3.org/TR/WCAG21/#exit-criteria<br />
<br />
==Full Site Conformance==<br />
Sites demonstrating conformance to WCAG 2.1:<br />
===At AA (8 needed):===<br />
# Knowbilty wants to make their knowability.org WCAG 2.1 compliant. Glenda spoke to Sharron, Eric Eggert & Robert Jolly. So, assuming their redesign stays on schedule and they don't hit any major glitches with WCAG 2.1 compliance...knowbility.org will be a WCAG 2.1 A/AA implementation example!<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
#<br />
<br />
===At AAA (2 needed): ===<br />
# lflegal.com (expressed interest)<br />
# <br />
# <br />
#<br />
<br />
==Individual SC Implementations==<br />
===Level A===<br />
====2.4.11 Character Key Shortcuts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Gmail (character-key shortcuts are not alternate controls, but can be changed by the user)<br />
* WordPress (character-key shortcuts for comments are alternate controls that can be switched off by the user)<br />
* [https://www.youtube.com/watch?v=xzSyIA4OWYE Single character key shortcuts adversely affecting speech input – example 1 Gdocs]<br />
* [https://www.youtube.com/watch?v=OPjfpDU9S08 Single character key shortcuts adversely affecting speech input – example 2 Twitter]<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.4.12 Label in Name====<br />
Sites demonstrating successful implementation of this SC:<br />
* Jake will find 2-3 example sites - Mike Gower can confirm<br />
* David MacDonald says Google home page is excellent passing example<br />
<br />
'''PASS'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
www.Google.com search field. Visible label is the button "Google Search" and ACCNAME is aria-label="Search"<br />
<br />
<br />
TEXT<br />
<br />
* http://www.bbc.com/ => all links in top menu and in doormat match<br />
* https://www.nytimes.com/ => all links in top menu and in doormat match<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.microsoft.com/en-us => Logo top left has name "Microsoft"<br />
* https://www.netflix.com/ => Logo top left has name "Netflix"<br />
* https://www.uber.com/en-NL/ => Below doormat the 3 app stores logo's have a title attribute with same text (except the Apple one, it has one word different)<br />
<br />
'''Accessible starts with Visible. The accessible name begins with the visible label.'''<br />
<br />
TEXT<br />
<br />
* https://www.google.com => when opening top right menu (3x3 squares), on bottom is "More" link and name is "More Google apps"<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.deque.com/ => The 'banner links' with "More information here" and "Get the free Download" start with visible text supplemented with additional info<br />
<br />
'''FAIL'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
<br />
TEXT<br />
<br />
* https://www.wikipedia.org => Search field has language dropdown with text "EN" but has name "English" (or other language when selected)<br />
<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://edition.cnn.com => CNN logo top left without alt text, url is read and CNN is part of URL but this is not official for the calculation<br />
* https://edition.cnn.com => CNN doormat links (Money, entertainment, tech, travel etc.) without alt text, url is read and text is part of URL but this is not official for the calculation<br />
* https://en.wikipedia.org/wiki/Main_Page => Logo top left has text "Wikipedia The Free Encyclopedia" but name "Visit the main page". <br />
* https://en.wikipedia.org/wiki/Main_Page => bottom right logo/text "a wikimedia project", with name "Wikimedia foundation"<br />
* https://www.telegraaf.nl/ => Text logo's at bottom for other section of the site have no name, URL is being read<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.1 Pointer Gestures====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/O7hibkNRTxk indiatimes.com (video of interaction on iPhone)]. The India times.com start page (8. February 2018) has a horizontal slider which can be moved with a one-finger swipe gesture. There are arrow buttons to the left and right of the slider which allow advancing the content with a single finger tap. So this would pass SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/TmEsQkJcpgk Ebay.com Start Page (video of interaction on Android smartphone)]. The Ebay start page (8. February 2018) has a content slider which can be moved with a one finger swipe gesture. There is alternative in one arrow button on top of the slider which leads to another page which has the same content as a slider. Arguably, this would pass SC 2.5.1 Pointer Gestures since a single finger tap accesses an equivalent alternative.<br />
# [https://youtu.be/s13KtPgqQBw Walmart.com start page (video of interaction on Android Smartphone)]. The Walmart homepage (8.February 2018) has a horizontal slider which can be moved with a one finger gesture. There are dots below the slider which allow setting the position of the slider through a single finger tap, So the would pass SC 2.5.1 Pointer Gestures.<br />
<br />
Sites demonstrating a failure of meeting this SC:<br />
# [https://youtu.be/vwnV5CAVtVA Guardian.co.uk start page (video of trackpad interaction on MacBook pro)]. The Guardian homepage (8. February 2018) has a slider element with videos which can be moved with a two-finger swipe gesture on the trackpad (MacBook pro OS X 10.11.6) (one-finger swipe on iPhone with iOS 11 ) There is no alternative to move the slider content so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/KYIX0e9uYBg Drag-and-Drop example (video of interaction on iPhone)]. The [http://marcojakob.github.io/dart-dnd/basic/web/ Drag-and-drop example by Marco Jacob] (recorded 8. February 2018) shows how file icons are dragged to a waste basket to delete the files. There is no single tap alternative for deletion, so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/SbyHxdXkgew North2.net Drag-and-drop (video of interaction] In the section "About us", the design agency north2.net (9. February 2018) uses drag-and-drop to select members of staff (video shows desktop interaction in Windows / Firefox - the drag-and-drop functionality is not presented on a smartphone). On the desktop, there seems to be no other way to select staff so this would fail SC 2.5.1 Pointer Gestures.<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.2 Pointer Cancellation====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* https://wet-boew.github.io/v4.0-ci/demos/formvalid/formvalid-en.html<br />
Submit form does not activate on the down event, the View Code disclosures are on the up event.<br />
* https://signup.com/<br />
"Start planning" button activates on the up event.<br />
<br />
Techniques proposed:<br />
* Using standard HTML buttons and links. (All standard interactive elements in HTML are on the up event.<br />
* Using JavaScript "onkeyup" and "onmouseup" attributes to activate controls.<br />
<br />
====2.6.1 Motion Actuation====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/KBqI4YXDH18 Web form pasting, Shake-to-undo (video of interaction on iPhone)]. After pasting an account number into the text input field of a library web app ([http://buecherhallen.de buecherhallen.de], 9. February 2018), shaking the iPhone brings up a dialog to confirm or cancel the undo action. ‘Shake to undo’ input can be disabled in the OS settings, so this would meet SC 2.6.1 Motion Actuation.<br />
<br />
Sites demonstrating failure of conforming to this SC:<br />
# [https://youtu.be/b0AIR17Xz2g Regnskogfondet move-device-to-pan (video of interaction)]. The site [http://rainforest.arkivert.no/ rainforest.arkivert.no] (9. February 2018) pans an interactive panorama when the user moves the device in a 360 degrees circle. There is no other way to pan the panorama to reach the embedded circular image links, so this would fail SC 2.6.1 Motion Actuation.<br />
<br />
*Kathy will check notes<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
===Level AA===<br />
<br />
==== 1.3.4 Identify Common Purpose ====<br />
Sites demonstrating successful implementation of this SC:<br />
* John Foliot will look<br />
* <br />
<br />
Techniques proposed:<br />
* <br />
<br />
====1.4.10 Reflow====<br />
Sites demonstrating successful implementation of this SC:<br />
* Texas School for the Blind and Visually Impaired [https://www.tsbvi.edu www.tsbvi.edu] - zoom page or hit Mobile button at top right of content<br />
* other<br />
<br />
Techniques proposed:<br />
* Using media queries (CSS). Ref: [http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ em based media queries] AND<br />
* @@ New: Using CSS grids to reflow content (CSS). Ref: [http://alistapart.com/article/fluidgrids fluid grids] OR<br />
* @@ New: [https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Using CSS Flexbox to reflow content (CSS)] OR<br />
* [https://www.w3.org/TR/WCAG20-TECHS/SCR34 SCR34: Calculating size and position in a way that scales with text size (Scripting)]<br />
* [https://www.w3.org/TR/WCAG20-TECHS/G206 G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text]<br />
<br />
====1.4.11 Non-Text Contrast====<br />
Sites demonstrating successful implementation of this SC:<br />
Glenda volunteered to find examples<br />
# State Farm https://www.statefarm.com/ <br />
## Graphical Objects - icons <br />
## Visual Focus Indicators <br />
# Accessibility at Penn State | Charts & Accessibility - http://accessibility.psu.edu/images/charts/ <br />
## Graphical Objects - charts/graphs <br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====1.4.12 Text Spacing====<br />
Sites demonstrating successful implementation of this SC:<br />
* [https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78 Results of Bookmarklet Tests for Issue 78] - Alastair Campbell, Amani Ali, Glenda Sims, Laura Carlson (67 pages were tested between July 25 and August 3, 2017)<br />
* [https://github.com/w3c/wcag21/issues/677#issuecomment-358043678 3 possible Japanese pages] - Makoto<br />
<br />
Techniques proposed:<br />
* [https://www.w3.org/WAI/GL/wiki/Allowing_for_Spacing_Override Allowing for Spacing Override (Draft)]<br />
<br />
====1.4.13 Content on Hover or Focus====<br />
Sites demonstrating successful implementation of this SC:<br />
* Steve R<br />
<br />
Techniques proposed:<br />
* ARIA: Using role="tooltip"<br />
* CSS: Using hover and focus pseudo classes<br />
<br />
====2.6.2 Orientation====<br />
Sites demonstrating successful implementation of this SC:<br />
* Marc Johlic<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====3.2.6 Status Changes====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* https://www.benefitcosmetics.com/us/en#<br />
Shopping Bag status message is a number beside the shopping bag. JAWS announces the number of item as it changes.<br />
<br />
* https://www.oct.ca/<br />
Search input on the home page (top right)<br />
Type in a keyword and press Enter. Screen reader announces "Searched for [term]. Your search returned x results."<br />
<br />
Techniques proposed:<br />
* Using aria-live regions to announce status messages to screen readers.<br />
* Using aria-live region roles to announce status messages to screen readers.<br />
<br />
===Level AAA===<br />
==== 1.3.5 Identify Purpose====<br />
Sites demonstrating successful implementation of this SC:<br />
* Lisa<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.6 Timeouts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Need to review how we tested this in 2.0<br />
* Airline booking sites?<br />
* Mike Gower<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.7 Animation from Interactions====<br />
<br />
Definitely failing examples:<br />
* [https://www.nytimes.com/interactive/2016/09/30/opinion/penn-station-reborn.html?_r=1 NYT Penn startion article]<br />
* [http://taotajima.jp/works/waxing-moon/ http://taotajima.jp/works/waxing-moon/] WARNING! Immediate severe vestibular trigger warning.<br />
<br />
Sites demonstrating successful implementation of this SC:<br />
<br />
1. On the [https://www.apple.com/iphone/photography-how-to/ iPhone photography how-to] page, it changes if you have the reduced-motion preference set (Safari on OSX/iOS). <br />
* Video does not play automatically.<br />
* The changes on mouse-over take place (an image appears), but the background image does not zoom in gradually.<br />
<br />
2. On the [https://www.apple.com/environment/ Apple Environment page] the tilting solar panels animation (triggered by scrolling) does not take place with the reduce-motion preference turned on. NB: The green sun is still animated, but that is an in-place animation, not triggered by interaction. Several other animations are also stopped, including the packaging and materials panels.<br />
<br />
Techniques proposed:<br />
* Using the reduced motion preference to prevent animation triggered by scrolling or other interactions.<br />
* Button to turn off animations triggered by scrolling.<br />
<br />
====2.5.3 Target Size====<br />
Sites demonstrating successful implementation of this SC:<br />
* Codepen https://codepen.io/<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.4 Concurrent Input Mechanisms====<br />
Sites demonstrating successful implementation of this SC:<br />
* Sway sites?<br />
* Chuck<br />
<br />
Techniques proposed:<br />
*<br />
*</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1_Implementations&diff=9404WCAG 2.1 Implementations2018-02-13T17:46:09Z<p>Dmacdona: /* 3.2.6 Status Changes */</p>
<hr />
<div>Until the resource for implementation information is available, this page will collect information about implementations.<br />
<br />
==Exit Criteria:==<br />
https://www.w3.org/TR/WCAG21/#exit-criteria<br />
<br />
==Full Site Conformance==<br />
Sites demonstrating conformance to WCAG 2.1:<br />
===At AA (8 needed):===<br />
# Knowbilty wants to make their knowability.org WCAG 2.1 compliant. Glenda spoke to Sharron, Eric Eggert & Robert Jolly. So, assuming their redesign stays on schedule and they don't hit any major glitches with WCAG 2.1 compliance...knowbility.org will be a WCAG 2.1 A/AA implementation example!<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
#<br />
<br />
===At AAA (2 needed): ===<br />
# lflegal.com (expressed interest)<br />
# <br />
# <br />
#<br />
<br />
==Individual SC Implementations==<br />
===Level A===<br />
====2.4.11 Character Key Shortcuts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Gmail (character-key shortcuts are not alternate controls, but can be changed by the user)<br />
* WordPress (character-key shortcuts for comments are alternate controls that can be switched off by the user)<br />
* [https://www.youtube.com/watch?v=xzSyIA4OWYE Single character key shortcuts adversely affecting speech input – example 1 Gdocs]<br />
* [https://www.youtube.com/watch?v=OPjfpDU9S08 Single character key shortcuts adversely affecting speech input – example 2 Twitter]<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.4.12 Label in Name====<br />
Sites demonstrating successful implementation of this SC:<br />
* Jake will find 2-3 example sites - Mike Gower can confirm<br />
* David MacDonald says Google home page is excellent passing example<br />
<br />
'''PASS'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
www.Google.com search field. Visible label is the button "Google Search" and ACCNAME is aria-label="Search"<br />
<br />
<br />
TEXT<br />
<br />
* http://www.bbc.com/ => all links in top menu and in doormat match<br />
* https://www.nytimes.com/ => all links in top menu and in doormat match<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.microsoft.com/en-us => Logo top left has name "Microsoft"<br />
* https://www.netflix.com/ => Logo top left has name "Netflix"<br />
* https://www.uber.com/en-NL/ => Below doormat the 3 app stores logo's have a title attribute with same text (except the Apple one, it has one word different)<br />
<br />
'''Accessible starts with Visible. The accessible name begins with the visible label.'''<br />
<br />
TEXT<br />
<br />
* https://www.google.com => when opening top right menu (3x3 squares), on bottom is "More" link and name is "More Google apps"<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.deque.com/ => The 'banner links' with "More information here" and "Get the free Download" start with visible text supplemented with additional info<br />
<br />
'''FAIL'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
<br />
TEXT<br />
<br />
* https://www.wikipedia.org => Search field has language dropdown with text "EN" but has name "English" (or other language when selected)<br />
<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://edition.cnn.com => CNN logo top left without alt text, url is read and CNN is part of URL but this is not official for the calculation<br />
* https://edition.cnn.com => CNN doormat links (Money, entertainment, tech, travel etc.) without alt text, url is read and text is part of URL but this is not official for the calculation<br />
* https://en.wikipedia.org/wiki/Main_Page => Logo top left has text "Wikipedia The Free Encyclopedia" but name "Visit the main page". <br />
* https://en.wikipedia.org/wiki/Main_Page => bottom right logo/text "a wikimedia project", with name "Wikimedia foundation"<br />
* https://www.telegraaf.nl/ => Text logo's at bottom for other section of the site have no name, URL is being read<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.1 Pointer Gestures====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/O7hibkNRTxk indiatimes.com (video of interaction on iPhone)]. The India times.com start page (8. February 2018) has a horizontal slider which can be moved with a one-finger swipe gesture. There are arrow buttons to the left and right of the slider which allow advancing the content with a single finger tap. So this would pass SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/TmEsQkJcpgk Ebay.com Start Page (video of interaction on Android smartphone)]. The Ebay start page (8. February 2018) has a content slider which can be moved with a one finger swipe gesture. There is alternative in one arrow button on top of the slider which leads to another page which has the same content as a slider. Arguably, this would pass SC 2.5.1 Pointer Gestures since a single finger tap accesses an equivalent alternative.<br />
# [https://youtu.be/s13KtPgqQBw Walmart.com start page (video of interaction on Android Smartphone)]. The Walmart homepage (8.February 2018) has a horizontal slider which can be moved with a one finger gesture. There are dots below the slider which allow setting the position of the slider through a single finger tap, So the would pass SC 2.5.1 Pointer Gestures.<br />
<br />
Sites demonstrating a failure of meeting this SC:<br />
# [https://youtu.be/vwnV5CAVtVA Guardian.co.uk start page (video of trackpad interaction on MacBook pro)]. The Guardian homepage (8. February 2018) has a slider element with videos which can be moved with a two-finger swipe gesture on the trackpad (MacBook pro OS X 10.11.6) (one-finger swipe on iPhone with iOS 11 ) There is no alternative to move the slider content so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/KYIX0e9uYBg Drag-and-Drop example (video of interaction on iPhone)]. The [http://marcojakob.github.io/dart-dnd/basic/web/ Drag-and-drop example by Marco Jacob] (recorded 8. February 2018) shows how file icons are dragged to a waste basket to delete the files. There is no single tap alternative for deletion, so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/SbyHxdXkgew North2.net Drag-and-drop (video of interaction] In the section "About us", the design agency north2.net (9. February 2018) uses drag-and-drop to select members of staff (video shows desktop interaction in Windows / Firefox - the drag-and-drop functionality is not presented on a smartphone). On the desktop, there seems to be no other way to select staff so this would fail SC 2.5.1 Pointer Gestures.<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.2 Pointer Cancellation====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* https://wet-boew.github.io/v4.0-ci/demos/formvalid/formvalid-en.html<br />
Submit form does not activate on the down event, the View Code disclosures are on the up event.<br />
* https://signup.com/<br />
"Start planning" button activates on the up event.<br />
<br />
Techniques proposed:<br />
* Using standard HTML buttons and links. (All standard interactive elements in HTML are on the up event.<br />
* Using JavaScript "onkeyup" and "onmouseup" attributes to activate controls.<br />
<br />
====2.6.1 Motion Actuation====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/KBqI4YXDH18 Web form pasting, Shake-to-undo (video of interaction on iPhone)]. After pasting an account number into the text input field of a library web app ([http://buecherhallen.de buecherhallen.de], 9. February 2018), shaking the iPhone brings up a dialog to confirm or cancel the undo action. ‘Shake to undo’ input can be disabled in the OS settings, so this would meet SC 2.6.1 Motion Actuation.<br />
<br />
Sites demonstrating failure of conforming to this SC:<br />
# [https://youtu.be/b0AIR17Xz2g Regnskogfondet move-device-to-pan (video of interaction)]. The site [http://rainforest.arkivert.no/ rainforest.arkivert.no] (9. February 2018) pans an interactive panorama when the user moves the device in a 360 degrees circle. There is no other way to pan the panorama to reach the embedded circular image links, so this would fail SC 2.6.1 Motion Actuation.<br />
<br />
*Kathy will check notes<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
===Level AA===<br />
<br />
==== 1.3.4 Identify Common Purpose ====<br />
Sites demonstrating successful implementation of this SC:<br />
* John Foliot will look<br />
* <br />
<br />
Techniques proposed:<br />
* <br />
<br />
====1.4.10 Reflow====<br />
Sites demonstrating successful implementation of this SC:<br />
* Texas School for the Blind and Visually Impaired [https://www.tsbvi.edu www.tsbvi.edu] - zoom page or hit Mobile button at top right of content<br />
* other<br />
<br />
Techniques proposed:<br />
* Using media queries (CSS). Ref: [http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ em based media queries] AND<br />
* @@ New: Using CSS grids to reflow content (CSS). Ref: [http://alistapart.com/article/fluidgrids fluid grids] OR<br />
* @@ New: [https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Using CSS Flexbox to reflow content (CSS)] OR<br />
* [https://www.w3.org/TR/WCAG20-TECHS/SCR34 SCR34: Calculating size and position in a way that scales with text size (Scripting)]<br />
* [https://www.w3.org/TR/WCAG20-TECHS/G206 G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text]<br />
<br />
====1.4.11 Non-Text Contrast====<br />
Sites demonstrating successful implementation of this SC:<br />
Glenda volunteered to find examples<br />
# State Farm https://www.statefarm.com/ <br />
## Graphical Objects - icons <br />
## Visual Focus Indicators <br />
# Accessibility at Penn State | Charts & Accessibility - http://accessibility.psu.edu/images/charts/ <br />
## Graphical Objects - charts/graphs <br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====1.4.12 Text Spacing====<br />
Sites demonstrating successful implementation of this SC:<br />
* [https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78 Results of Bookmarklet Tests for Issue 78] - Alastair Campbell, Amani Ali, Glenda Sims, Laura Carlson (67 pages were tested between July 25 and August 3, 2017)<br />
* [https://github.com/w3c/wcag21/issues/677#issuecomment-358043678 3 possible Japanese pages] - Makoto<br />
<br />
Techniques proposed:<br />
* [https://www.w3.org/WAI/GL/wiki/Allowing_for_Spacing_Override Allowing for Spacing Override (Draft)]<br />
<br />
====1.4.13 Content on Hover or Focus====<br />
Sites demonstrating successful implementation of this SC:<br />
* Steve R<br />
<br />
Techniques proposed:<br />
* ARIA: Using role="tooltip"<br />
* CSS: Using hover and focus pseudo classes<br />
<br />
====2.6.2 Orientation====<br />
Sites demonstrating successful implementation of this SC:<br />
* Marc Johlic<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====3.2.6 Status Changes====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* https://www.benefitcosmetics.com/us/en#<br />
Shopping Bag status message is a number beside the shopping bag. JAWS announces the number of item as it changes.<br />
<br />
Techniques proposed:<br />
*<br />
*<br />
<br />
===Level AAA===<br />
==== 1.3.5 Identify Purpose====<br />
Sites demonstrating successful implementation of this SC:<br />
* Lisa<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.6 Timeouts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Need to review how we tested this in 2.0<br />
* Airline booking sites?<br />
* Mike Gower<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.7 Animation from Interactions====<br />
<br />
Definitely failing examples:<br />
* [https://www.nytimes.com/interactive/2016/09/30/opinion/penn-station-reborn.html?_r=1 NYT Penn startion article]<br />
* [http://taotajima.jp/works/waxing-moon/ http://taotajima.jp/works/waxing-moon/] WARNING! Immediate severe vestibular trigger warning.<br />
<br />
Sites demonstrating successful implementation of this SC:<br />
<br />
1. On the [https://www.apple.com/iphone/photography-how-to/ iPhone photography how-to] page, it changes if you have the reduced-motion preference set (Safari on OSX/iOS). <br />
* Video does not play automatically.<br />
* The changes on mouse-over take place (an image appears), but the background image does not zoom in gradually.<br />
<br />
2. On the [https://www.apple.com/environment/ Apple Environment page] the tilting solar panels animation (triggered by scrolling) does not take place with the reduce-motion preference turned on. NB: The green sun is still animated, but that is an in-place animation, not triggered by interaction. Several other animations are also stopped, including the packaging and materials panels.<br />
<br />
Techniques proposed:<br />
* Using the reduced motion preference to prevent animation triggered by scrolling or other interactions.<br />
* Button to turn off animations triggered by scrolling.<br />
<br />
====2.5.3 Target Size====<br />
Sites demonstrating successful implementation of this SC:<br />
* Codepen https://codepen.io/<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.4 Concurrent Input Mechanisms====<br />
Sites demonstrating successful implementation of this SC:<br />
* Sway sites?<br />
* Chuck<br />
<br />
Techniques proposed:<br />
*<br />
*</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1_Implementations&diff=9403WCAG 2.1 Implementations2018-02-13T17:26:26Z<p>Dmacdona: /* 2.5.2 Pointer Cancellation */</p>
<hr />
<div>Until the resource for implementation information is available, this page will collect information about implementations.<br />
<br />
==Exit Criteria:==<br />
https://www.w3.org/TR/WCAG21/#exit-criteria<br />
<br />
==Full Site Conformance==<br />
Sites demonstrating conformance to WCAG 2.1:<br />
===At AA (8 needed):===<br />
# Knowbilty wants to make their knowability.org WCAG 2.1 compliant. Glenda spoke to Sharron, Eric Eggert & Robert Jolly. So, assuming their redesign stays on schedule and they don't hit any major glitches with WCAG 2.1 compliance...knowbility.org will be a WCAG 2.1 A/AA implementation example!<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
#<br />
<br />
===At AAA (2 needed): ===<br />
# lflegal.com (expressed interest)<br />
# <br />
# <br />
#<br />
<br />
==Individual SC Implementations==<br />
===Level A===<br />
====2.4.11 Character Key Shortcuts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Gmail (character-key shortcuts are not alternate controls, but can be changed by the user)<br />
* WordPress (character-key shortcuts for comments are alternate controls that can be switched off by the user)<br />
* [https://www.youtube.com/watch?v=xzSyIA4OWYE Single character key shortcuts adversely affecting speech input – example 1 Gdocs]<br />
* [https://www.youtube.com/watch?v=OPjfpDU9S08 Single character key shortcuts adversely affecting speech input – example 2 Twitter]<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.4.12 Label in Name====<br />
Sites demonstrating successful implementation of this SC:<br />
* Jake will find 2-3 example sites - Mike Gower can confirm<br />
* David MacDonald says Google home page is excellent passing example<br />
<br />
'''PASS'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
www.Google.com search field. Visible label is the button "Google Search" and ACCNAME is aria-label="Search"<br />
<br />
<br />
TEXT<br />
<br />
* http://www.bbc.com/ => all links in top menu and in doormat match<br />
* https://www.nytimes.com/ => all links in top menu and in doormat match<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.microsoft.com/en-us => Logo top left has name "Microsoft"<br />
* https://www.netflix.com/ => Logo top left has name "Netflix"<br />
* https://www.uber.com/en-NL/ => Below doormat the 3 app stores logo's have a title attribute with same text (except the Apple one, it has one word different)<br />
<br />
'''Accessible starts with Visible. The accessible name begins with the visible label.'''<br />
<br />
TEXT<br />
<br />
* https://www.google.com => when opening top right menu (3x3 squares), on bottom is "More" link and name is "More Google apps"<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.deque.com/ => The 'banner links' with "More information here" and "Get the free Download" start with visible text supplemented with additional info<br />
<br />
'''FAIL'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
<br />
TEXT<br />
<br />
* https://www.wikipedia.org => Search field has language dropdown with text "EN" but has name "English" (or other language when selected)<br />
<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://edition.cnn.com => CNN logo top left without alt text, url is read and CNN is part of URL but this is not official for the calculation<br />
* https://edition.cnn.com => CNN doormat links (Money, entertainment, tech, travel etc.) without alt text, url is read and text is part of URL but this is not official for the calculation<br />
* https://en.wikipedia.org/wiki/Main_Page => Logo top left has text "Wikipedia The Free Encyclopedia" but name "Visit the main page". <br />
* https://en.wikipedia.org/wiki/Main_Page => bottom right logo/text "a wikimedia project", with name "Wikimedia foundation"<br />
* https://www.telegraaf.nl/ => Text logo's at bottom for other section of the site have no name, URL is being read<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.1 Pointer Gestures====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/O7hibkNRTxk indiatimes.com (video of interaction on iPhone)]. The India times.com start page (8. February 2018) has a horizontal slider which can be moved with a one-finger swipe gesture. There are arrow buttons to the left and right of the slider which allow advancing the content with a single finger tap. So this would pass SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/TmEsQkJcpgk Ebay.com Start Page (video of interaction on Android smartphone)]. The Ebay start page (8. February 2018) has a content slider which can be moved with a one finger swipe gesture. There is alternative in one arrow button on top of the slider which leads to another page which has the same content as a slider. Arguably, this would pass SC 2.5.1 Pointer Gestures since a single finger tap accesses an equivalent alternative.<br />
# [https://youtu.be/s13KtPgqQBw Walmart.com start page (video of interaction on Android Smartphone)]. The Walmart homepage (8.February 2018) has a horizontal slider which can be moved with a one finger gesture. There are dots below the slider which allow setting the position of the slider through a single finger tap, So the would pass SC 2.5.1 Pointer Gestures.<br />
<br />
Sites demonstrating a failure of meeting this SC:<br />
# [https://youtu.be/vwnV5CAVtVA Guardian.co.uk start page (video of trackpad interaction on MacBook pro)]. The Guardian homepage (8. February 2018) has a slider element with videos which can be moved with a two-finger swipe gesture on the trackpad (MacBook pro OS X 10.11.6) (one-finger swipe on iPhone with iOS 11 ) There is no alternative to move the slider content so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/KYIX0e9uYBg Drag-and-Drop example (video of interaction on iPhone)]. The [http://marcojakob.github.io/dart-dnd/basic/web/ Drag-and-drop example by Marco Jacob] (recorded 8. February 2018) shows how file icons are dragged to a waste basket to delete the files. There is no single tap alternative for deletion, so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/SbyHxdXkgew North2.net Drag-and-drop (video of interaction] In the section "About us", the design agency north2.net (9. February 2018) uses drag-and-drop to select members of staff (video shows desktop interaction in Windows / Firefox - the drag-and-drop functionality is not presented on a smartphone). On the desktop, there seems to be no other way to select staff so this would fail SC 2.5.1 Pointer Gestures.<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.2 Pointer Cancellation====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* https://wet-boew.github.io/v4.0-ci/demos/formvalid/formvalid-en.html<br />
Submit form does not activate on the down event, the View Code disclosures are on the up event.<br />
* https://signup.com/<br />
"Start planning" button activates on the up event.<br />
<br />
Techniques proposed:<br />
* Using standard HTML buttons and links. (All standard interactive elements in HTML are on the up event.<br />
* Using JavaScript "onkeyup" and "onmouseup" attributes to activate controls.<br />
<br />
====2.6.1 Motion Actuation====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/KBqI4YXDH18 Web form pasting, Shake-to-undo (video of interaction on iPhone)]. After pasting an account number into the text input field of a library web app ([http://buecherhallen.de buecherhallen.de], 9. February 2018), shaking the iPhone brings up a dialog to confirm or cancel the undo action. ‘Shake to undo’ input can be disabled in the OS settings, so this would meet SC 2.6.1 Motion Actuation.<br />
<br />
Sites demonstrating failure of conforming to this SC:<br />
# [https://youtu.be/b0AIR17Xz2g Regnskogfondet move-device-to-pan (video of interaction)]. The site [http://rainforest.arkivert.no/ rainforest.arkivert.no] (9. February 2018) pans an interactive panorama when the user moves the device in a 360 degrees circle. There is no other way to pan the panorama to reach the embedded circular image links, so this would fail SC 2.6.1 Motion Actuation.<br />
<br />
*Kathy will check notes<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
===Level AA===<br />
<br />
==== 1.3.4 Identify Common Purpose ====<br />
Sites demonstrating successful implementation of this SC:<br />
* John Foliot will look<br />
* <br />
<br />
Techniques proposed:<br />
* <br />
<br />
====1.4.10 Reflow====<br />
Sites demonstrating successful implementation of this SC:<br />
* Texas School for the Blind and Visually Impaired [https://www.tsbvi.edu www.tsbvi.edu] - zoom page or hit Mobile button at top right of content<br />
* other<br />
<br />
Techniques proposed:<br />
* Using media queries (CSS). Ref: [http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ em based media queries] AND<br />
* @@ New: Using CSS grids to reflow content (CSS). Ref: [http://alistapart.com/article/fluidgrids fluid grids] OR<br />
* @@ New: [https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Using CSS Flexbox to reflow content (CSS)] OR<br />
* [https://www.w3.org/TR/WCAG20-TECHS/SCR34 SCR34: Calculating size and position in a way that scales with text size (Scripting)]<br />
* [https://www.w3.org/TR/WCAG20-TECHS/G206 G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text]<br />
<br />
====1.4.11 Non-Text Contrast====<br />
Sites demonstrating successful implementation of this SC:<br />
Glenda volunteered to find examples<br />
# State Farm https://www.statefarm.com/ <br />
## Graphical Objects - icons <br />
## Visual Focus Indicators <br />
# Accessibility at Penn State | Charts & Accessibility - http://accessibility.psu.edu/images/charts/ <br />
## Graphical Objects - charts/graphs <br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====1.4.12 Text Spacing====<br />
Sites demonstrating successful implementation of this SC:<br />
* [https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78 Results of Bookmarklet Tests for Issue 78] - Alastair Campbell, Amani Ali, Glenda Sims, Laura Carlson (67 pages were tested between July 25 and August 3, 2017)<br />
* [https://github.com/w3c/wcag21/issues/677#issuecomment-358043678 3 possible Japanese pages] - Makoto<br />
<br />
Techniques proposed:<br />
* [https://www.w3.org/WAI/GL/wiki/Allowing_for_Spacing_Override Allowing for Spacing Override (Draft)]<br />
<br />
====1.4.13 Content on Hover or Focus====<br />
Sites demonstrating successful implementation of this SC:<br />
* Steve R<br />
<br />
Techniques proposed:<br />
* ARIA: Using role="tooltip"<br />
* CSS: Using hover and focus pseudo classes<br />
<br />
====2.6.2 Orientation====<br />
Sites demonstrating successful implementation of this SC:<br />
* Marc Johlic<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====3.2.6 Status Changes====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
<br />
Techniques proposed:<br />
*<br />
* <br />
<br />
<br />
<br />
===Level AAA===<br />
==== 1.3.5 Identify Purpose====<br />
Sites demonstrating successful implementation of this SC:<br />
* Lisa<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.6 Timeouts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Need to review how we tested this in 2.0<br />
* Airline booking sites?<br />
* Mike Gower<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.7 Animation from Interactions====<br />
<br />
Definitely failing examples:<br />
* [https://www.nytimes.com/interactive/2016/09/30/opinion/penn-station-reborn.html?_r=1 NYT Penn startion article]<br />
* [http://taotajima.jp/works/waxing-moon/ http://taotajima.jp/works/waxing-moon/] WARNING! Immediate severe vestibular trigger warning.<br />
<br />
Sites demonstrating successful implementation of this SC:<br />
<br />
1. On the [https://www.apple.com/iphone/photography-how-to/ iPhone photography how-to] page, it changes if you have the reduced-motion preference set (Safari on OSX/iOS). <br />
* Video does not play automatically.<br />
* The changes on mouse-over take place (an image appears), but the background image does not zoom in gradually.<br />
<br />
2. On the [https://www.apple.com/environment/ Apple Environment page] the tilting solar panels animation (triggered by scrolling) does not take place with the reduce-motion preference turned on. NB: The green sun is still animated, but that is an in-place animation, not triggered by interaction. Several other animations are also stopped, including the packaging and materials panels.<br />
<br />
Techniques proposed:<br />
* Using the reduced motion preference to prevent animation triggered by scrolling or other interactions.<br />
* Button to turn off animations triggered by scrolling.<br />
<br />
====2.5.3 Target Size====<br />
Sites demonstrating successful implementation of this SC:<br />
* Codepen https://codepen.io/<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.4 Concurrent Input Mechanisms====<br />
Sites demonstrating successful implementation of this SC:<br />
* Sway sites?<br />
* Chuck<br />
<br />
Techniques proposed:<br />
*<br />
*</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1_Implementations&diff=9402WCAG 2.1 Implementations2018-02-13T17:24:23Z<p>Dmacdona: /* 2.5.2 Pointer Cancellation */</p>
<hr />
<div>Until the resource for implementation information is available, this page will collect information about implementations.<br />
<br />
==Exit Criteria:==<br />
https://www.w3.org/TR/WCAG21/#exit-criteria<br />
<br />
==Full Site Conformance==<br />
Sites demonstrating conformance to WCAG 2.1:<br />
===At AA (8 needed):===<br />
# Knowbilty wants to make their knowability.org WCAG 2.1 compliant. Glenda spoke to Sharron, Eric Eggert & Robert Jolly. So, assuming their redesign stays on schedule and they don't hit any major glitches with WCAG 2.1 compliance...knowbility.org will be a WCAG 2.1 A/AA implementation example!<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
#<br />
<br />
===At AAA (2 needed): ===<br />
# lflegal.com (expressed interest)<br />
# <br />
# <br />
#<br />
<br />
==Individual SC Implementations==<br />
===Level A===<br />
====2.4.11 Character Key Shortcuts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Gmail (character-key shortcuts are not alternate controls, but can be changed by the user)<br />
* WordPress (character-key shortcuts for comments are alternate controls that can be switched off by the user)<br />
* [https://www.youtube.com/watch?v=xzSyIA4OWYE Single character key shortcuts adversely affecting speech input – example 1 Gdocs]<br />
* [https://www.youtube.com/watch?v=OPjfpDU9S08 Single character key shortcuts adversely affecting speech input – example 2 Twitter]<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.4.12 Label in Name====<br />
Sites demonstrating successful implementation of this SC:<br />
* Jake will find 2-3 example sites - Mike Gower can confirm<br />
* David MacDonald says Google home page is excellent passing example<br />
<br />
'''PASS'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
www.Google.com search field. Visible label is the button "Google Search" and ACCNAME is aria-label="Search"<br />
<br />
<br />
TEXT<br />
<br />
* http://www.bbc.com/ => all links in top menu and in doormat match<br />
* https://www.nytimes.com/ => all links in top menu and in doormat match<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.microsoft.com/en-us => Logo top left has name "Microsoft"<br />
* https://www.netflix.com/ => Logo top left has name "Netflix"<br />
* https://www.uber.com/en-NL/ => Below doormat the 3 app stores logo's have a title attribute with same text (except the Apple one, it has one word different)<br />
<br />
'''Accessible starts with Visible. The accessible name begins with the visible label.'''<br />
<br />
TEXT<br />
<br />
* https://www.google.com => when opening top right menu (3x3 squares), on bottom is "More" link and name is "More Google apps"<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.deque.com/ => The 'banner links' with "More information here" and "Get the free Download" start with visible text supplemented with additional info<br />
<br />
'''FAIL'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
<br />
TEXT<br />
<br />
* https://www.wikipedia.org => Search field has language dropdown with text "EN" but has name "English" (or other language when selected)<br />
<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://edition.cnn.com => CNN logo top left without alt text, url is read and CNN is part of URL but this is not official for the calculation<br />
* https://edition.cnn.com => CNN doormat links (Money, entertainment, tech, travel etc.) without alt text, url is read and text is part of URL but this is not official for the calculation<br />
* https://en.wikipedia.org/wiki/Main_Page => Logo top left has text "Wikipedia The Free Encyclopedia" but name "Visit the main page". <br />
* https://en.wikipedia.org/wiki/Main_Page => bottom right logo/text "a wikimedia project", with name "Wikimedia foundation"<br />
* https://www.telegraaf.nl/ => Text logo's at bottom for other section of the site have no name, URL is being read<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.1 Pointer Gestures====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/O7hibkNRTxk indiatimes.com (video of interaction on iPhone)]. The India times.com start page (8. February 2018) has a horizontal slider which can be moved with a one-finger swipe gesture. There are arrow buttons to the left and right of the slider which allow advancing the content with a single finger tap. So this would pass SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/TmEsQkJcpgk Ebay.com Start Page (video of interaction on Android smartphone)]. The Ebay start page (8. February 2018) has a content slider which can be moved with a one finger swipe gesture. There is alternative in one arrow button on top of the slider which leads to another page which has the same content as a slider. Arguably, this would pass SC 2.5.1 Pointer Gestures since a single finger tap accesses an equivalent alternative.<br />
# [https://youtu.be/s13KtPgqQBw Walmart.com start page (video of interaction on Android Smartphone)]. The Walmart homepage (8.February 2018) has a horizontal slider which can be moved with a one finger gesture. There are dots below the slider which allow setting the position of the slider through a single finger tap, So the would pass SC 2.5.1 Pointer Gestures.<br />
<br />
Sites demonstrating a failure of meeting this SC:<br />
# [https://youtu.be/vwnV5CAVtVA Guardian.co.uk start page (video of trackpad interaction on MacBook pro)]. The Guardian homepage (8. February 2018) has a slider element with videos which can be moved with a two-finger swipe gesture on the trackpad (MacBook pro OS X 10.11.6) (one-finger swipe on iPhone with iOS 11 ) There is no alternative to move the slider content so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/KYIX0e9uYBg Drag-and-Drop example (video of interaction on iPhone)]. The [http://marcojakob.github.io/dart-dnd/basic/web/ Drag-and-drop example by Marco Jacob] (recorded 8. February 2018) shows how file icons are dragged to a waste basket to delete the files. There is no single tap alternative for deletion, so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/SbyHxdXkgew North2.net Drag-and-drop (video of interaction] In the section "About us", the design agency north2.net (9. February 2018) uses drag-and-drop to select members of staff (video shows desktop interaction in Windows / Firefox - the drag-and-drop functionality is not presented on a smartphone). On the desktop, there seems to be no other way to select staff so this would fail SC 2.5.1 Pointer Gestures.<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.2 Pointer Cancellation====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* https://wet-boew.github.io/v4.0-ci/demos/formvalid/formvalid-en.html<br />
Submit form does not activate on the down event, the View Code disclosures are on the up event.<br />
* https://signup.com/<br />
"Start planning" button activates on the up event.<br />
<br />
Techniques proposed:<br />
* Using standard HTML buttons and links. (All standard interactive elements in HTML are on the up event.<br />
* Using JavaScript<br />
<br />
====2.6.1 Motion Actuation====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/KBqI4YXDH18 Web form pasting, Shake-to-undo (video of interaction on iPhone)]. After pasting an account number into the text input field of a library web app ([http://buecherhallen.de buecherhallen.de], 9. February 2018), shaking the iPhone brings up a dialog to confirm or cancel the undo action. ‘Shake to undo’ input can be disabled in the OS settings, so this would meet SC 2.6.1 Motion Actuation.<br />
<br />
Sites demonstrating failure of conforming to this SC:<br />
# [https://youtu.be/b0AIR17Xz2g Regnskogfondet move-device-to-pan (video of interaction)]. The site [http://rainforest.arkivert.no/ rainforest.arkivert.no] (9. February 2018) pans an interactive panorama when the user moves the device in a 360 degrees circle. There is no other way to pan the panorama to reach the embedded circular image links, so this would fail SC 2.6.1 Motion Actuation.<br />
<br />
*Kathy will check notes<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
===Level AA===<br />
<br />
==== 1.3.4 Identify Common Purpose ====<br />
Sites demonstrating successful implementation of this SC:<br />
* John Foliot will look<br />
* <br />
<br />
Techniques proposed:<br />
* <br />
<br />
====1.4.10 Reflow====<br />
Sites demonstrating successful implementation of this SC:<br />
* Texas School for the Blind and Visually Impaired [https://www.tsbvi.edu www.tsbvi.edu] - zoom page or hit Mobile button at top right of content<br />
* other<br />
<br />
Techniques proposed:<br />
* Using media queries (CSS). Ref: [http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ em based media queries] AND<br />
* @@ New: Using CSS grids to reflow content (CSS). Ref: [http://alistapart.com/article/fluidgrids fluid grids] OR<br />
* @@ New: [https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Using CSS Flexbox to reflow content (CSS)] OR<br />
* [https://www.w3.org/TR/WCAG20-TECHS/SCR34 SCR34: Calculating size and position in a way that scales with text size (Scripting)]<br />
* [https://www.w3.org/TR/WCAG20-TECHS/G206 G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text]<br />
<br />
====1.4.11 Non-Text Contrast====<br />
Sites demonstrating successful implementation of this SC:<br />
Glenda volunteered to find examples<br />
# State Farm https://www.statefarm.com/ <br />
## Graphical Objects - icons <br />
## Visual Focus Indicators <br />
# Accessibility at Penn State | Charts & Accessibility - http://accessibility.psu.edu/images/charts/ <br />
## Graphical Objects - charts/graphs <br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====1.4.12 Text Spacing====<br />
Sites demonstrating successful implementation of this SC:<br />
* [https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78 Results of Bookmarklet Tests for Issue 78] - Alastair Campbell, Amani Ali, Glenda Sims, Laura Carlson (67 pages were tested between July 25 and August 3, 2017)<br />
* [https://github.com/w3c/wcag21/issues/677#issuecomment-358043678 3 possible Japanese pages] - Makoto<br />
<br />
Techniques proposed:<br />
* [https://www.w3.org/WAI/GL/wiki/Allowing_for_Spacing_Override Allowing for Spacing Override (Draft)]<br />
<br />
====1.4.13 Content on Hover or Focus====<br />
Sites demonstrating successful implementation of this SC:<br />
* Steve R<br />
<br />
Techniques proposed:<br />
* ARIA: Using role="tooltip"<br />
* CSS: Using hover and focus pseudo classes<br />
<br />
====2.6.2 Orientation====<br />
Sites demonstrating successful implementation of this SC:<br />
* Marc Johlic<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====3.2.6 Status Changes====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
<br />
Techniques proposed:<br />
*<br />
* <br />
<br />
<br />
<br />
===Level AAA===<br />
==== 1.3.5 Identify Purpose====<br />
Sites demonstrating successful implementation of this SC:<br />
* Lisa<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.6 Timeouts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Need to review how we tested this in 2.0<br />
* Airline booking sites?<br />
* Mike Gower<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.7 Animation from Interactions====<br />
<br />
Definitely failing examples:<br />
* [https://www.nytimes.com/interactive/2016/09/30/opinion/penn-station-reborn.html?_r=1 NYT Penn startion article]<br />
* [http://taotajima.jp/works/waxing-moon/ http://taotajima.jp/works/waxing-moon/] WARNING! Immediate severe vestibular trigger warning.<br />
<br />
Sites demonstrating successful implementation of this SC:<br />
<br />
1. On the [https://www.apple.com/iphone/photography-how-to/ iPhone photography how-to] page, it changes if you have the reduced-motion preference set (Safari on OSX/iOS). <br />
* Video does not play automatically.<br />
* The changes on mouse-over take place (an image appears), but the background image does not zoom in gradually.<br />
<br />
2. On the [https://www.apple.com/environment/ Apple Environment page] the tilting solar panels animation (triggered by scrolling) does not take place with the reduce-motion preference turned on. NB: The green sun is still animated, but that is an in-place animation, not triggered by interaction. Several other animations are also stopped, including the packaging and materials panels.<br />
<br />
Techniques proposed:<br />
* Using the reduced motion preference to prevent animation triggered by scrolling or other interactions.<br />
* Button to turn off animations triggered by scrolling.<br />
<br />
====2.5.3 Target Size====<br />
Sites demonstrating successful implementation of this SC:<br />
* Codepen https://codepen.io/<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.4 Concurrent Input Mechanisms====<br />
Sites demonstrating successful implementation of this SC:<br />
* Sway sites?<br />
* Chuck<br />
<br />
Techniques proposed:<br />
*<br />
*</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1_Implementations&diff=9401WCAG 2.1 Implementations2018-02-13T17:15:36Z<p>Dmacdona: /* 2.5.2 Pointer Cancellation */</p>
<hr />
<div>Until the resource for implementation information is available, this page will collect information about implementations.<br />
<br />
==Exit Criteria:==<br />
https://www.w3.org/TR/WCAG21/#exit-criteria<br />
<br />
==Full Site Conformance==<br />
Sites demonstrating conformance to WCAG 2.1:<br />
===At AA (8 needed):===<br />
# Knowbilty wants to make their knowability.org WCAG 2.1 compliant. Glenda spoke to Sharron, Eric Eggert & Robert Jolly. So, assuming their redesign stays on schedule and they don't hit any major glitches with WCAG 2.1 compliance...knowbility.org will be a WCAG 2.1 A/AA implementation example!<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
#<br />
<br />
===At AAA (2 needed): ===<br />
# lflegal.com (expressed interest)<br />
# <br />
# <br />
#<br />
<br />
==Individual SC Implementations==<br />
===Level A===<br />
====2.4.11 Character Key Shortcuts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Gmail (character-key shortcuts are not alternate controls, but can be changed by the user)<br />
* WordPress (character-key shortcuts for comments are alternate controls that can be switched off by the user)<br />
* [https://www.youtube.com/watch?v=xzSyIA4OWYE Single character key shortcuts adversely affecting speech input – example 1 Gdocs]<br />
* [https://www.youtube.com/watch?v=OPjfpDU9S08 Single character key shortcuts adversely affecting speech input – example 2 Twitter]<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.4.12 Label in Name====<br />
Sites demonstrating successful implementation of this SC:<br />
* Jake will find 2-3 example sites - Mike Gower can confirm<br />
* David MacDonald says Google home page is excellent passing example<br />
<br />
'''PASS'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
www.Google.com search field. Visible label is the button "Google Search" and ACCNAME is aria-label="Search"<br />
<br />
<br />
TEXT<br />
<br />
* http://www.bbc.com/ => all links in top menu and in doormat match<br />
* https://www.nytimes.com/ => all links in top menu and in doormat match<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.microsoft.com/en-us => Logo top left has name "Microsoft"<br />
* https://www.netflix.com/ => Logo top left has name "Netflix"<br />
* https://www.uber.com/en-NL/ => Below doormat the 3 app stores logo's have a title attribute with same text (except the Apple one, it has one word different)<br />
<br />
'''Accessible starts with Visible. The accessible name begins with the visible label.'''<br />
<br />
TEXT<br />
<br />
* https://www.google.com => when opening top right menu (3x3 squares), on bottom is "More" link and name is "More Google apps"<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.deque.com/ => The 'banner links' with "More information here" and "Get the free Download" start with visible text supplemented with additional info<br />
<br />
'''FAIL'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
<br />
TEXT<br />
<br />
* https://www.wikipedia.org => Search field has language dropdown with text "EN" but has name "English" (or other language when selected)<br />
<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://edition.cnn.com => CNN logo top left without alt text, url is read and CNN is part of URL but this is not official for the calculation<br />
* https://edition.cnn.com => CNN doormat links (Money, entertainment, tech, travel etc.) without alt text, url is read and text is part of URL but this is not official for the calculation<br />
* https://en.wikipedia.org/wiki/Main_Page => Logo top left has text "Wikipedia The Free Encyclopedia" but name "Visit the main page". <br />
* https://en.wikipedia.org/wiki/Main_Page => bottom right logo/text "a wikimedia project", with name "Wikimedia foundation"<br />
* https://www.telegraaf.nl/ => Text logo's at bottom for other section of the site have no name, URL is being read<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.1 Pointer Gestures====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/O7hibkNRTxk indiatimes.com (video of interaction on iPhone)]. The India times.com start page (8. February 2018) has a horizontal slider which can be moved with a one-finger swipe gesture. There are arrow buttons to the left and right of the slider which allow advancing the content with a single finger tap. So this would pass SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/TmEsQkJcpgk Ebay.com Start Page (video of interaction on Android smartphone)]. The Ebay start page (8. February 2018) has a content slider which can be moved with a one finger swipe gesture. There is alternative in one arrow button on top of the slider which leads to another page which has the same content as a slider. Arguably, this would pass SC 2.5.1 Pointer Gestures since a single finger tap accesses an equivalent alternative.<br />
# [https://youtu.be/s13KtPgqQBw Walmart.com start page (video of interaction on Android Smartphone)]. The Walmart homepage (8.February 2018) has a horizontal slider which can be moved with a one finger gesture. There are dots below the slider which allow setting the position of the slider through a single finger tap, So the would pass SC 2.5.1 Pointer Gestures.<br />
<br />
Sites demonstrating a failure of meeting this SC:<br />
# [https://youtu.be/vwnV5CAVtVA Guardian.co.uk start page (video of trackpad interaction on MacBook pro)]. The Guardian homepage (8. February 2018) has a slider element with videos which can be moved with a two-finger swipe gesture on the trackpad (MacBook pro OS X 10.11.6) (one-finger swipe on iPhone with iOS 11 ) There is no alternative to move the slider content so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/KYIX0e9uYBg Drag-and-Drop example (video of interaction on iPhone)]. The [http://marcojakob.github.io/dart-dnd/basic/web/ Drag-and-drop example by Marco Jacob] (recorded 8. February 2018) shows how file icons are dragged to a waste basket to delete the files. There is no single tap alternative for deletion, so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/SbyHxdXkgew North2.net Drag-and-drop (video of interaction] In the section "About us", the design agency north2.net (9. February 2018) uses drag-and-drop to select members of staff (video shows desktop interaction in Windows / Firefox - the drag-and-drop functionality is not presented on a smartphone). On the desktop, there seems to be no other way to select staff so this would fail SC 2.5.1 Pointer Gestures.<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.2 Pointer Cancellation====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* https://wet-boew.github.io/v4.0-ci/demos/formvalid/formvalid-en.html<br />
Submit form does not activate on the down event, the View Code disclosures are on the up event.<br />
<br />
Techniques proposed:<br />
* Using standard HTML buttons and links. (All standard interactive elements in HTML are on the up event.<br />
* Using JavaScript<br />
<br />
====2.6.1 Motion Actuation====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/KBqI4YXDH18 Web form pasting, Shake-to-undo (video of interaction on iPhone)]. After pasting an account number into the text input field of a library web app ([http://buecherhallen.de buecherhallen.de], 9. February 2018), shaking the iPhone brings up a dialog to confirm or cancel the undo action. ‘Shake to undo’ input can be disabled in the OS settings, so this would meet SC 2.6.1 Motion Actuation.<br />
<br />
Sites demonstrating failure of conforming to this SC:<br />
# [https://youtu.be/b0AIR17Xz2g Regnskogfondet move-device-to-pan (video of interaction)]. The site [http://rainforest.arkivert.no/ rainforest.arkivert.no] (9. February 2018) pans an interactive panorama when the user moves the device in a 360 degrees circle. There is no other way to pan the panorama to reach the embedded circular image links, so this would fail SC 2.6.1 Motion Actuation.<br />
<br />
*Kathy will check notes<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
===Level AA===<br />
<br />
==== 1.3.4 Identify Common Purpose ====<br />
Sites demonstrating successful implementation of this SC:<br />
* John Foliot will look<br />
* <br />
<br />
Techniques proposed:<br />
* <br />
<br />
====1.4.10 Reflow====<br />
Sites demonstrating successful implementation of this SC:<br />
* Texas School for the Blind and Visually Impaired [https://www.tsbvi.edu www.tsbvi.edu] - zoom page or hit Mobile button at top right of content<br />
* other<br />
<br />
Techniques proposed:<br />
* Using media queries (CSS). Ref: [http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ em based media queries] AND<br />
* @@ New: Using CSS grids to reflow content (CSS). Ref: [http://alistapart.com/article/fluidgrids fluid grids] OR<br />
* @@ New: [https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Using CSS Flexbox to reflow content (CSS)] OR<br />
* [https://www.w3.org/TR/WCAG20-TECHS/SCR34 SCR34: Calculating size and position in a way that scales with text size (Scripting)]<br />
* [https://www.w3.org/TR/WCAG20-TECHS/G206 G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text]<br />
<br />
====1.4.11 Non-Text Contrast====<br />
Sites demonstrating successful implementation of this SC:<br />
Glenda volunteered to find examples<br />
# State Farm https://www.statefarm.com/ <br />
## Graphical Objects - icons <br />
## Visual Focus Indicators <br />
# Accessibility at Penn State | Charts & Accessibility - http://accessibility.psu.edu/images/charts/ <br />
## Graphical Objects - charts/graphs <br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====1.4.12 Text Spacing====<br />
Sites demonstrating successful implementation of this SC:<br />
* [https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78 Results of Bookmarklet Tests for Issue 78] - Alastair Campbell, Amani Ali, Glenda Sims, Laura Carlson (67 pages were tested between July 25 and August 3, 2017)<br />
* [https://github.com/w3c/wcag21/issues/677#issuecomment-358043678 3 possible Japanese pages] - Makoto<br />
<br />
Techniques proposed:<br />
* [https://www.w3.org/WAI/GL/wiki/Allowing_for_Spacing_Override Allowing for Spacing Override (Draft)]<br />
<br />
====1.4.13 Content on Hover or Focus====<br />
Sites demonstrating successful implementation of this SC:<br />
* Steve R<br />
<br />
Techniques proposed:<br />
* ARIA: Using role="tooltip"<br />
* CSS: Using hover and focus pseudo classes<br />
<br />
====2.6.2 Orientation====<br />
Sites demonstrating successful implementation of this SC:<br />
* Marc Johlic<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====3.2.6 Status Changes====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
<br />
Techniques proposed:<br />
*<br />
* <br />
<br />
<br />
<br />
===Level AAA===<br />
==== 1.3.5 Identify Purpose====<br />
Sites demonstrating successful implementation of this SC:<br />
* Lisa<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.6 Timeouts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Need to review how we tested this in 2.0<br />
* Airline booking sites?<br />
* Mike Gower<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.7 Animation from Interactions====<br />
<br />
Definitely failing examples:<br />
* [https://www.nytimes.com/interactive/2016/09/30/opinion/penn-station-reborn.html?_r=1 NYT Penn startion article]<br />
* [http://taotajima.jp/works/waxing-moon/ http://taotajima.jp/works/waxing-moon/] WARNING! Immediate severe vestibular trigger warning.<br />
<br />
Sites demonstrating successful implementation of this SC:<br />
<br />
1. On the [https://www.apple.com/iphone/photography-how-to/ iPhone photography how-to] page, it changes if you have the reduced-motion preference set (Safari on OSX/iOS). <br />
* Video does not play automatically.<br />
* The changes on mouse-over take place (an image appears), but the background image does not zoom in gradually.<br />
<br />
2. On the [https://www.apple.com/environment/ Apple Environment page] the tilting solar panels animation (triggered by scrolling) does not take place with the reduce-motion preference turned on. NB: The green sun is still animated, but that is an in-place animation, not triggered by interaction. Several other animations are also stopped, including the packaging and materials panels.<br />
<br />
Techniques proposed:<br />
* Using the reduced motion preference to prevent animation triggered by scrolling or other interactions.<br />
* Button to turn off animations triggered by scrolling.<br />
<br />
====2.5.3 Target Size====<br />
Sites demonstrating successful implementation of this SC:<br />
* Codepen https://codepen.io/<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.4 Concurrent Input Mechanisms====<br />
Sites demonstrating successful implementation of this SC:<br />
* Sway sites?<br />
* Chuck<br />
<br />
Techniques proposed:<br />
*<br />
*</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1_Implementations&diff=9397WCAG 2.1 Implementations2018-02-13T17:02:31Z<p>Dmacdona: /* 2.4.12 Label in Name */</p>
<hr />
<div>Until the resource for implementation information is available, this page will collect information about implementations.<br />
<br />
==Exit Criteria:==<br />
https://www.w3.org/TR/WCAG21/#exit-criteria<br />
<br />
==Full Site Conformance==<br />
Sites demonstrating conformance to WCAG 2.1:<br />
===At AA (8 needed):===<br />
# Perhaps we could ask our dear friends at Knowbilty if they could make this site WCAG 2.1 compliant: https://air-rallies.org/<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
#<br />
<br />
===At AAA (2 needed): ===<br />
# lflegal.com (expressed interest)<br />
# <br />
# <br />
#<br />
<br />
==Individual SC Implementations==<br />
===Level A===<br />
====2.4.11 Character Key Shortcuts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Gmail (character-key shortcuts are not alternate controls, but can be changed by the user)<br />
* WordPress (character-key shortcuts for comments are alternate controls that can be switched off by the user)<br />
* [https://www.youtube.com/watch?v=xzSyIA4OWYE Single character key shortcuts adversely affecting speech input – example 1 Gdocs]<br />
* [https://www.youtube.com/watch?v=OPjfpDU9S08 Single character key shortcuts adversely affecting speech input – example 2 Twitter]<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.4.12 Label in Name====<br />
Sites demonstrating successful implementation of this SC:<br />
* Jake will find 2-3 example sites - Mike Gower can confirm<br />
* David MacDonald says Google home page is excellent passing example<br />
<br />
'''PASS'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
www.Google.com search field. Visible label is the button "Google Search" and ACCNAME is aria-label="Search"<br />
<br />
<br />
TEXT<br />
<br />
* http://www.bbc.com/ => all links in top menu and in doormat match<br />
* https://www.nytimes.com/ => all links in top menu and in doormat match<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.microsoft.com/en-us => Logo top left has name "Microsoft"<br />
* https://www.netflix.com/ => Logo top left has name "Netflix"<br />
* https://www.uber.com/en-NL/ => Below doormat the 3 app stores logo's have a title attribute with same text (except the Apple one, it has one word different)<br />
<br />
'''Accessible starts with Visible. The accessible name begins with the visible label.'''<br />
<br />
TEXT<br />
<br />
* https://www.google.com => when opening top right menu (3x3 squares), on bottom is "More" link and name is "More Google apps"<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://www.deque.com/ => The 'banner links' with "More information here" and "Get the free Download" start with visible text supplemented with additional info<br />
<br />
'''FAIL'''<br />
<br />
'''Accessible matches Visible. The visible and accessible name of a label match'''<br />
<br />
TEXT<br />
<br />
* https://www.wikipedia.org => Search field has language dropdown with text "EN" but has name "English" (or other language when selected)<br />
<br />
<br />
IMAGES OF TEXT<br />
<br />
* https://edition.cnn.com => CNN logo top left without alt text, url is read and CNN is part of URL but this is not official for the calculation<br />
* https://edition.cnn.com => CNN doormat links (Money, entertainment, tech, travel etc.) without alt text, url is read and text is part of URL but this is not official for the calculation<br />
* https://en.wikipedia.org/wiki/Main_Page => Logo top left has text "Wikipedia The Free Encyclopedia" but name "Visit the main page". <br />
* https://en.wikipedia.org/wiki/Main_Page => bottom right logo/text "a wikimedia project", with name "Wikimedia foundation"<br />
* https://www.telegraaf.nl/ => Text logo's at bottom for other section of the site have no name, URL is being read<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.1 Pointer Gestures====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/O7hibkNRTxk indiatimes.com (video of interaction on iPhone)]. The India times.com start page (8. February 2018) has a horizontal slider which can be moved with a one-finger swipe gesture. There are arrow buttons to the left and right of the slider which allow advancing the content with a single finger tap. So this would pass SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/TmEsQkJcpgk Ebay.com Start Page (video of interaction on Android smartphone)]. The Ebay start page (8. February 2018) has a content slider which can be moved with a one finger swipe gesture. There is alternative in one arrow button on top of the slider which leads to another page which has the same content as a slider. Arguably, this would pass SC 2.5.1 Pointer Gestures since a single finger tap accesses an equivalent alternative.<br />
# [https://youtu.be/s13KtPgqQBw Walmart.com start page (video of interaction on Android Smartphone)]. The Walmart homepage (8.February 2018) has a horizontal slider which can be moved with a one finger gesture. There are dots below the slider which allow setting the position of the slider through a single finger tap, So the would pass SC 2.5.1 Pointer Gestures.<br />
<br />
Sites demonstrating a failure of meeting this SC:<br />
# [https://youtu.be/vwnV5CAVtVA Guardian.co.uk start page (video of trackpad interaction on MacBook pro)]. The Guardian homepage (8. February 2018) has a slider element with videos which can be moved with a two-finger swipe gesture on the trackpad (MacBook pro OS X 10.11.6) (one-finger swipe on iPhone with iOS 11 ) There is no alternative to move the slider content so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/KYIX0e9uYBg Drag-and-Drop example (video of interaction on iPhone)]. The [http://marcojakob.github.io/dart-dnd/basic/web/ Drag-and-drop example by Marco Jacob] (recorded 8. February 2018) shows how file icons are dragged to a waste basket to delete the files. There is no single tap alternative for deletion, so this would fail SC 2.5.1 Pointer Gestures.<br />
# [https://youtu.be/SbyHxdXkgew North2.net Drag-and-drop (video of interaction] In the section "About us", the design agency north2.net (9. February 2018) uses drag-and-drop to select members of staff (video shows desktop interaction in Windows / Firefox - the drag-and-drop functionality is not presented on a smartphone). On the desktop, there seems to be no other way to select staff so this would fail SC 2.5.1 Pointer Gestures.<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====2.5.2 Pointer Cancellation====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
* <br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.6.1 Motion Actuation====<br />
Sites demonstrating successful implementation of this SC:<br />
# [https://youtu.be/KBqI4YXDH18 Web form pasting, Shake-to-undo (video of interaction on iPhone)]. After pasting an account number into the text input field of a library web app ([http://buecherhallen.de buecherhallen.de], 9. February 2018), shaking the iPhone brings up a dialog to confirm or cancel the undo action. ‘Shake to undo’ input can be disabled in the OS settings, so this would meet SC 2.6.1 Motion Actuation.<br />
<br />
Sites demonstrating failure of conforming to this SC:<br />
# [https://youtu.be/b0AIR17Xz2g Regnskogfondet move-device-to-pan (video of interaction)]. The site [http://rainforest.arkivert.no/ rainforest.arkivert.no] (9. February 2018) pans an interactive panorama when the user moves the device in a 360 degrees circle. There is no other way to pan the panorama to reach the embedded circular image links, so this would fail SC 2.6.1 Motion Actuation.<br />
<br />
*Kathy will check notes<br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
===Level AA===<br />
<br />
==== 1.3.4 Identify Common Purpose ====<br />
Sites demonstrating successful implementation of this SC:<br />
* John Foliot will look<br />
* <br />
<br />
Techniques proposed:<br />
* <br />
<br />
====1.4.10 Reflow====<br />
Sites demonstrating successful implementation of this SC:<br />
* Texas School for the Blind and Visually Impaired [https://www.tsbvi.edu www.tsbvi.edu] - zoom page or hit Mobile button at top right of content<br />
* other<br />
<br />
Techniques proposed:<br />
* Using media queries (CSS). Ref: [http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/ em based media queries] AND<br />
* @@ New: Using CSS grids to reflow content (CSS). Ref: [http://alistapart.com/article/fluidgrids fluid grids] OR<br />
* @@ New: [https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Using CSS Flexbox to reflow content (CSS)] OR<br />
* [https://www.w3.org/TR/WCAG20-TECHS/SCR34 SCR34: Calculating size and position in a way that scales with text size (Scripting)]<br />
* [https://www.w3.org/TR/WCAG20-TECHS/G206 G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text]<br />
<br />
====1.4.11 Non-Text Contrast====<br />
Sites demonstrating successful implementation of this SC:<br />
Glenda volunteered to find examples<br />
# State Farm https://www.statefarm.com/ <br />
## Graphical Objects - icons <br />
## Visual Focus Indicators <br />
# Accessibility at Penn State | Charts & Accessibility - http://accessibility.psu.edu/images/charts/ <br />
## Graphical Objects - charts/graphs <br />
<br />
Techniques proposed:<br />
* <br />
*<br />
<br />
====1.4.12 Text Spacing====<br />
Sites demonstrating successful implementation of this SC:<br />
* [https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78 Results of Bookmarklet Tests for Issue 78] - Alastair Campbell, Amani Ali, Glenda Sims, Laura Carlson (67 pages were tested between July 25 and August 3, 2017)<br />
* [https://github.com/w3c/wcag21/issues/677#issuecomment-358043678 3 possible Japanese pages] - Makoto<br />
<br />
Techniques proposed:<br />
* [https://www.w3.org/WAI/GL/wiki/Allowing_for_Spacing_Override Allowing for Spacing Override (Draft)]<br />
<br />
====1.4.13 Content on Hover or Focus====<br />
Sites demonstrating successful implementation of this SC:<br />
* Steve R<br />
<br />
Techniques proposed:<br />
* ARIA: Using role="tooltip"<br />
* CSS: Using hover and focus pseudo classes<br />
<br />
====2.6.2 Orientation====<br />
Sites demonstrating successful implementation of this SC:<br />
* Marc Johlic<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====3.2.6 Status Changes====<br />
Sites demonstrating successful implementation of this SC:<br />
* David MacDonald<br />
<br />
Techniques proposed:<br />
*<br />
* <br />
<br />
<br />
<br />
===Level AAA===<br />
==== 1.3.5 Identify Purpose====<br />
Sites demonstrating successful implementation of this SC:<br />
* Lisa<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.6 Timeouts====<br />
Sites demonstrating successful implementation of this SC:<br />
* Need to review how we tested this in 2.0<br />
* Airline booking sites?<br />
* Mike Gower<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.2.7 Animation from Interactions====<br />
<br />
Definitely failing examples:<br />
* [https://www.nytimes.com/interactive/2016/09/30/opinion/penn-station-reborn.html?_r=1 NYT Penn startion article]<br />
* [http://taotajima.jp/works/waxing-moon/ http://taotajima.jp/works/waxing-moon/] WARNING! Immediate severe vestibular trigger warning.<br />
<br />
Sites demonstrating successful implementation of this SC:<br />
<br />
On the [https://www.apple.com/iphone/photography-how-to/ iPhone photography how-to] page, it changes if you have the reduced-motion preference set (Safari on OSX/iOS). <br />
* Video does not play automatically.<br />
* The changes on mouse-over take place (an image appears), but the background image does not zoom in gradually.<br />
<br />
On the [https://www.apple.com/environment/ Apple Environment page] the tilting solar panels animation (triggered by scrolling) does not take place with the reduce-motion preference turned on. NB: The green sun is still animated, but that is an in-place animation, not triggered by interaction. Several other animations are also stopped, including the packaging and materials panels.<br />
<br />
Techniques proposed:<br />
* Using the reduced motion preference to prevent animation triggered by scrolling or other interactions.<br />
* Button to turn off animations triggered by scrolling.<br />
<br />
====2.5.3 Target Size====<br />
Sites demonstrating successful implementation of this SC:<br />
* Kathy has examples<br />
<br />
Techniques proposed:<br />
* <br />
* <br />
<br />
====2.5.4 Concurrent Input Mechanisms====<br />
Sites demonstrating successful implementation of this SC:<br />
* Sway sites?<br />
* Chuck<br />
<br />
Techniques proposed:<br />
*<br />
*</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Draft_Response_issue_721&diff=9321Draft Response issue 7212018-01-22T13:52:46Z<p>Dmacdona: /* Proposed WG answer */</p>
<hr />
<div>== Answers to RNIB issue by issue ==<br />
=== 1.3.4 Identify Common Purpose ===<br />
Level: AA<br />
In other words: What a control does.<br />
<br />
However, it is helpful to have something that identifies the action rather than just the role. The workload required is an issue not just for testers, but also for developers. We think we may see a lot of people failing this if it is AA. There will need to be some education around this for developers and some more support around how this should be tested.<br />
<br />
==== Proposed WG answer ====<br />
The changes in 1.3.4 make the SC apply only to input controls, and relate only to the expected meaning of the data being input about the user.<br />
<br />
=== 1.3.5 Contextual Information ===<br />
Level: AAA<br />
<br />
We strongly support this success criterion as anything that enables better delivery of effective personalization is going to be helpful to many people. We’d like to see some examples of how this personalization would work on individual websites and what the site needs to do to make personalization work effectively. More clarification is needed on what is meant by “publicly available vocabulary”. Some examples of what this means would be useful and clarity around how this vocabulary is going to be defined. Is this something determined by the W3C and utilised by all or will we have independent vocabularies everywhere which would be very challenging indeed and not really realistic? We think there needs to be more work on this. This success criterion also seems quite subjective and hence difficult to test. In addition, there may be parts of websites that, for example, are accessed via a log in (e.g. a medical site with information for Doctors) that has its own specialist vocabulary that is suitable and appropriate for those particular users – who will not be the general public.<br />
<br />
==== Proposed WG answer ====<br />
The SC has been renamed and is now called ''Identify Purpose''. We will work to clarify your questions in the understanding document.<br />
<br />
=== 1.4.10 Reflow ===<br />
Level: AA<br />
<br />
We agree in principle as the current resizing criteria are not quite effective enough and there are people who use more than 200% without magnification (perhaps not as far as 400%). One way to deliver this is responsive design but there is a possibility of failure if content or functionality is removed (https://www.w3.org/WAI/WCAG21/Understanding/21/reflow.html). There need to be good examples here regarding how to deliver this responsively highlighting the importance of not losing content or functionality. In addition, it may not be possible to do this for elements of websites such as videos – there needs to be clarity around how this is addressed.<br />
<br />
==== Proposed WG answer ====<br />
The Understanding document covers the issue of a potential loss of content in section "What happens if sites move/change things at smaller sizes?" There is no loss in terms of this SC if content is still available, e.g., hidden behind a show/hide button, or navigation is moved into a drop-down it is still available.<br />
Videos may either be responsively resized, or not resized, then falling under the exception at the end of the SC text: "..except for parts of the content that require two-dimensional layout for usage or meaning". So we think this issue is sufficiently covered.<br />
<br />
=== 1.4.11 Graphics Contrast ===<br />
Level: AA<br />
<br />
We strongly support this however feel the title is a bit ambiguous and needs to clarify that it applies not only to non-text content such as images, icons but also to user interface components.<br />
<br />
==== Proposed WG answer ====<br />
The SC title has been changed to ''Not-text contrast'' to make it clearer that it applies to graphical user interface components as well as to information-carrying graphics.<br />
<br />
=== 1.4.12 Text Spacing ===<br />
Level: AA<br />
<br />
We agree with the principle but have concerns that this will be difficult to test and more resources are needed. We are also concerned that this might be difficult to achieve for AA and perhaps should be AAA. We think more resources are needed to test this. There is a bookmarklet available: https://www.w3.org/WAI/GL/wiki/Results_of_Bookmarklet_Tests_for_Issue_78<br />
However, the bookmarklet does not work successfully on all sites (script refuses to load) so other resources will be needed.<br />
<br />
==== Proposed WG answer ====<br />
The working group has done testing on many sites, and the type of issues found are not particularly difficult to solve.<br />
<br />
The testing (and usage by people with low vision) can also be accompllished using the Stylish pluggin (Firefox and Chrome), which does work on sites with a restrictive content-security policy. At least one individual is also planning small test-focused plugins as well.<br />
<br />
=== 1.4.13 Content on Hover or Focus===<br />
Level: AA<br />
<br />
We strongly support this. However, testing will be a manual process and will be an overhead for “on hover” and there needs to be a clear indication of how to test this.<br />
<br />
==== Proposed WG answer ====<br />
The tests for this SC may be more manual than for some other SC at first, but we expect that additional tooling will be developed. The SC will only apply on web pages with hover content, so will not apply to every page.<br />
<br />
=== 2.2.6 Accessible Authentication === <br />
Level: A<br />
<br />
We strongly support this in principle. However, the implementation is key and case study examples are crucial to ensure that business requirements are catered for, especially as this is single A.<br />
<br />
==== Proposed WG answer ====<br />
<br />
The WG has not been able to reach consensus on this Success Criteria for inclusion in the Candidate Recommendation, so this SC has been removed from the current draft of WCAG 2.1 and deferred to a future version. We will consider your comment in our future work on this SC.<br />
<br />
=== 2.2.7 Interruptions (Minimum) === <br />
Level: AA<br />
<br />
We strongly support this particularly with there being more and more chat bots on sites and requests for feedback. It is important to have more clarification about what is a pass and what is a fail. A list with common “distractions” would be useful. A list of any exceptions, such as time notification, confirmation messages, error messages etc. is also needed. In addition, it is not clear whether users should be able to enable or disable the interruptions as the website loads – and what impact this has on the criterion. For example, a chat can be muted by default and users can choose to enable the sound notification, rather than the other way around. More thought is needed about implementation and how it will work in practice along with the required examples.<br />
<br />
==== Proposed WG answer ====<br />
<br />
The WG has not been able to reach consensus on this Success Criteria for inclusion in the Candidate Recommendation, so this SC has been removed from the current draft of WCAG 2.1 and deferred to a future version. We will consider your comment in our future work on this SC.<br />
<br />
=== 2.2.8 Timeouts === <br />
Where data can be lost due to user inactivity, users are warned about the estimated length of inactivity that generates the data loss, unless the data is preserved for a minimum of 20 hours of user inactivity.<br />
<br />
Level: AAA<br />
<br />
We agree with the principle. We have some concerns about the testability.<br />
<br />
==== Proposed WG answer ====<br />
We agree that this SC is difficult to test, especially the 'unless' condition. We note that same difficulty applies to Success Criterion ''2.2.1 Timing Adjustable'', which did not prevent that SC to be accepted in WCAG 2.0.<br />
<br />
=== 2.2.9 Animation from Interactions === <br />
Level: AAA<br />
<br />
We agree with the principle. Guidance is needed on how to implement this to ensure it is done well and is accessible and usable. To some extent it is disappointing that this is AAA rather than AA.<br />
<br />
==== Proposed WG response ====<br />
The Working Group will develop Techniques that show how this SC can be met. While the primary Technique might a General Technique for authors to avoid implementing parallax scrolling altogether, The Understanding Document http://rawgit.com/w3c/wcag21/master/understanding/21/animation-from-interactions.html already indicates two further Techniques, a General Technique for offering user settings to disable animation, and a CSS Technique for using media queries to prevent animation from interactions.<br />
<br />
=== 2.4.11 Character Key Shortcuts === <br />
Level: A<br />
<br />
We agree with this in principle but think the general text description of this SC is slightly confusing because of the language used. In particular, the last sentence of the paragraph may require some clarification. Although Character keys are described in the glossary, the description is not sufficient. Practically how will someone remap the keys? Is it realistic to expect a basic user to do this?<br />
<br />
==== Proposed WG answer ====<br />
We will clarify the SC in understanding and develop techniques.<br />
<br />
=== 2.4.12 Label in Name === <br />
Level: A<br />
<br />
We strongly support this in principle. Would this be able to be undertaken by automated testing if included in the software? If so we should ensure that we request that automated testing tools include this. If manual testing is required, this will be time consuming.<br />
<br />
==== Proposed WG answer ====<br />
This SC seems in principle suitable for inclusion in automatic testing. It is however not in scope of the WCAG Working Group to mandate the inclusion of such a check in vendors' automatic testing tools.<br />
<br />
=== 2.5 Guideline Pointer Accessible === <br />
Make it easier for users to operate pointer functionality<br />
<br />
We are adding this general guideline too as it is a new section. We think it is important to note that the text used to describe this general guideline is insufficient. Just saying ‘make it easier’ is not helpful for testing. Whilst there are more specifics further down in the SC we feel more clarity is needed.<br />
<br />
==== Proposed WG answer ====<br />
Guideline texts are not supposed to be the basis for testing. They indicate the general concerm and indicate the general direction of good practice, so they are unspecific by design. It is up to the text of the SCs that follow to specify how the respective criteria are to be tested (and up to Techniques to specify actual test procedures).<br />
<br />
=== 2.5.1 Pointer Gestures === <br />
Level: A<br />
<br />
We agree with the principle. We are not clear what a ‘path based gesture’ is? Is this clear enough or does it need a glossary link or better description? This seems more applicable on mobile/touch devices. Users must be able to perform touch functions with assistive technology or with one finger. It is not likely websites will have interactions that require multi-touch gestures. Testing would involve trying a multi-touch gesture and checking the same functionality can be achieved with one finger or assistive technology. This is likely to be time-consuming to test.<br />
<br />
==== Proposed WG answer ====<br />
Path-based gestures are any gestures where the user engages with a screen (e.g. touches or causes a mouse-down), moves the pointer, and then releases the finger or mouse at another location. The WG will still determine whether we need a definition.<br />
<br />
There are already web sites with content that require multipoint gestures, e.g. for the two-finger panning of a map.<br />
<br />
As to testing content, we expect that there will be techiques that can query web content for event listeners looking for events such as touchstart or touchend to identify pages whether the author has implemented touch gestures. However, looking for the existience of equivalent UI controls may at the time being remain a manual task.<br />
<br />
=== 2.5.2 Pointer Cancellation === <br />
Level: A<br />
<br />
We agree with the principle but think that the text for this SC needs some consideration as the full extent is not very clear. We are concerned about testing and how realistic this will be. In our experience developers are not always consistent with the way they implement controls. However, this is important as although we might not be seeing much of this at the moment, we think we might see this more in the future.<br />
<br />
Testing will be time consuming, all interactive elements will have to be checked by touch.<br />
<br />
==== Proposed WG answer ====<br />
The SC applies to all pointer input, no just touch, so it is not necessarily true that all interactive elements will have to be checked by touch. Automated checking procedures might support testing by looking out for particular event handlers such as touchdown and mousedown.<br />
<br />
=== 2.5.3 Target Size === <br />
Level: AA<br />
44 by 22 px<br />
<br />
We agree with the principle but would like to see what target size is being suggested in practice. It’s also important to assess whether it is reasonable to ask people for this to be single A as there is already a note on here that it is a minimum and it should be larger anyway.<br />
<br />
As things stand there is no clear indication on how to test this criterion. All interactive elements will need to have their dimensions tested and this seems a very consuming process.<br />
<br />
==== Proposed WG answer (Detlev) ====<br />
This SC has been removed from the WCAG 2.1 draft since the WG was not able to reach consensus.<br />
<br />
=== 2.5.4 Target Size (Enhanced) === <br />
Level: AAA<br />
44 by 44<br />
22 by 22 inline<br />
<br />
Again, would like to see what size this is in practice. Should there be an A, AA and AAA for target size or should AA be A and AAA be AA?<br />
<br />
==== Proposed WG answer ====<br />
We will provide examples in the understanding document.<br />
<br />
=== 2.5.5 Concurrent Input Mechanisms === <br />
Level: AAA<br />
<br />
We agree in principle, but are concerned about the practicalities of testing this. Is there a way of undertaking a generic test of code to check if input modalities are blocked rather than practical testing? It could be very complex to review.<br />
<br />
==== Proposed WG answer ====<br />
It is unlikely that a generic test will suffice, but we expect that a collection of more specific techniques will address much of the testing.<br />
<br />
=== 2.6.1 Motion Actuation === <br />
Level A<br />
<br />
We agree in principle, but are concerned about the practicalities of testing this. The criterion also could be better worded.<br />
<br />
==== Proposed WG answer ====<br />
We have renamed the first exception, "Accessibility supported". It now reads "Supported Interface: The motion is used to operate functionality through an accessibility supported interface". If you have other specific suggestions how the SC text could be improved, feel free to comment on the forthcoming Candidate Recommendation of WCAG 2.1.<br />
<br />
=== 2.6.2 Orientation === <br />
Level AA<br />
<br />
We strongly agree with the principle and agree that there are specific exemptions, but good examples of these specifics should be given to ensure that these are not used to avoid compliance.<br />
<br />
==== Proposed WG answer ====<br />
We agree that examples are helpful. That is why the note already mentions four cases where orientation may be essential. The Understanding text has three examples that show common scenarios in which change of orientation should work. However, examples can never enumerate all cases that may qualify for the essentrial exception. If you have examples that you would like to see included to show cases where exceptions would not qualify as essential, we welcome your suggestions and will extend the Understanding doc accordingly.<br />
<br />
=== 3.2.6 Status Changes === <br />
Level AA<br />
We strongly support this principle and wonder if there has been any consideration about this being single A? An example of adding an item to a shopping basket (where the action triggers a message ‘item added to basket’ which is announced by a screen reader and the user can continue navigating the content) is a good reason as to why this should be single A as well as success notification for forms.<br />
<br />
==== Proposed WG answer ====<br />
This SC was proposed at AA and the WG has not reached consensus on moving it to a different level.<br />
<br />
=== Other things of Note ===<br />
We wanted to flag these as we feel they are important issues from the RNIB’s perspective but appreciate it may not be possible to consider all these at this late stage.<br />
<br />
=== Read Only Fields === <br />
It is important to make sure that the focus can go to read only fields and enable the content to be read via a screen reader. This is essential for applications that are web-delivered where this is often seen.<br />
<br />
==== Proposed WG answer ====<br />
This is already covered by WCAG 2.0.<br />
<br />
=== Use of Headings === <br />
We would like to see the use of H1 on the page being better defined, specifically that it identifies the main content heading and where its location should be. This can be an issue for example on the Home page where often the logo is used as the H1.<br />
<br />
==== Proposed WG answer ====<br />
There are various ways out there to use headings. This question has already been addressed in WCAG 2.0, and at that time, the working group made the determination to not require an h1 beyond identifying the semantic structure when available on a page.<br />
<br />
We feel that it is beyond the scope of normative success criteria to mandate a particular headings usage pattern. If you have suggestions for a Sufficient or Advisory Technique around the use of h1 headings, feel free to suggest it, preferably at Github https://github.com/w3c/wcag/issues or via the Online submission form https://www.w3.org/WAI/WCAG20/comments/onlineform.<br />
<br />
=== Addition to Error Identification === <br />
We strongly support the provision of providing a summary of all error messages at the top of the form as well as inline. In addition, when the user presses submit, the focus should move to a message stating that there are errors on the form. Clarity over what is good practice is needed.<br />
<br />
==== Proposed WG answer ====<br />
There are various ways of implementing error handling. While the pattern you suggest is a best practice, the WG feels that it is beyond the scope of normative success criteria to mandate a particular usage pattern. If you have suggestions for Sufficient or Advisory Techniques around error handling, feel free to suggest them, preferably at Github https://github.com/w3c/wcag/issues or via the Online submission form https://www.w3.org/WAI/WCAG20/comments/onlineform</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Draft_Responses_to_Dec_WD_Issues&diff=9320Draft Responses to Dec WD Issues2018-01-22T13:31:40Z<p>Dmacdona: /* 520 */</p>
<hr />
<div>== This page contains draft responses to issues logged in GitHub ==<br />
Open issues: https://github.com/w3c/wcag21/labels/Dec%20WD%20Comment<br />
<br />
If your issue is not listed, please add it as a heading 3 and make sure to indicate who drafted the response. See below for examples to follow in terms of organization of the information.<br />
<br />
Please write the responses in a way that can be easily copied/pasted into the issue. For each issue the editors will add "Official WG response: Thank you for your comment." to the start, so it isn't necessary to include that in the response.<br />
<br />
When an item is approved by the WG it will be indicated in the heading.<br />
<br />
===331===<br />
https://github.com/w3c/wcag21/issues/331<br />
<br />
Proposed response:<br />
Thank you for the comment. We will remove this note from the conformance section and address this topic in the Understanding document.<br />
<br />
Alternate proposed response 1: <br />
Thank you for the comment. We will replace this note with a note that reads "Authors including multiple views of a page (e.g. using break points to provide different views at different screen sizes) need to consider each view when evaluating conformance. Please see Understanding Conformance Requirement 2 for more information." <br />
<br />
Alternate proposed response 2:<br />
Thank you for the comment. This note is non-normative (as are all notes) but does represent the consensus view of the Working Group.<br />
<br />
===342===<br />
https://github.com/w3c/wcag21/issues/342<br />
<br />
Thank you for the comment. Your core concern seems to be whether this SC is implementable and helpful. It is being added to the CR draft as an "at risk" item, so we aim to demonstrate this more clearly in the CR period.<br />
<br />
===366===<br />
https://github.com/w3c/wcag21/issues/366<br />
<br />
Proposed response:<br />
Thank you for the comment. We will remove this note from the conformance section and address this topic in the Understanding document.<br />
<br />
Alternate proposed response 1: <br />
Thank you for the comment. We will replace this note with a note that reads "Authors including multiple views of a page (e.g. using break points to provide different views at different screen sizes) need to consider each view when evaluating conformance. Please see Understanding Conformance Requirement 2 for more information." <br />
<br />
Alternate proposed response 2:<br />
Thank you for the comment. This note is non-normative (as are all notes) but does represent the consensus view of the Working Group.<br />
<br />
=== 631 ===<br />
https://github.com/w3c/wcag21/issues/631 .<br />
<br />
Thank you for your question. This Success Criteria was developed in the Mobile Task Force with the primary purpose to ensure that pointer targets are large enough for people with dexterity disabilities to hit the touch target in mobile, with the additional benefit of providing larger click targets for mouse users on desktop who have dexterity disabilities. This was not covered in WCAG 2.0. The task force looked at a number of studies and other standards, such as the BBC Mobile Guidelines. One study demonstrated that some people with dexterity disabilities needed a target size of 100px by 100px. So we knew that we could only provide a minimum value and encourage the author to make targets as large as possible. The idea of the minimum size requirement in the success criteria was to choose a value as large as possible without negatively impacting design. Google mobile developer guidelines recommended 48px by 48px. <br />
<br />
We took Apple's recommendation and amended one dimension in response to comments that 44px by 44px was too large for many interfaces, especially vertical lists of text links, and we added a list of exceptions, including specifying a smaller dimension (22px) for some situations. Unfortunately, the SC language was not able to be agreed on within the Working Group, and as a result the AA version of this SC has been removed from the draft.<br />
<br />
=== 636 ===<br />
https://github.com/w3c/wcag21/issues/636 (answer by Lisa) <br />
<br />
The new wording just requires that the purpose is programmatically determined. We will be adding techniques and have user agent support before we leave CR as per are exit criteria - see https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria.<br />
<br />
It is worth noting that success criteria specify what needs to be done but are never technology specific. How to reach them or what terms to use is always left to techniques. There are often more than one way to achieve success (such as using native html, xforms or ARIA)<br />
<br />
=== 651 ===<br />
https://github.com/w3c/wcag21/issues/651<br />
<br />
Proposed response: <br />
<br />
The SC has been updated to use what browsers currently implement, and there was already a great deal of overlap between what was required for inputs, and the HTML list.<br />
<br />
Once implemented, it seems unlikely that the browsers (and therefore the HTML spec) would reduce the list, unless there is a security issue with particular items.<br />
<br />
In future iterations that expand this requirement, the working group hopes there will be a stable specification to directly reference for that purpose, but this seems to be a reasonable starting point.<br />
<br />
The SC text has been updated to show that it should only be used in technologies that support it, and the understanding and techniques will clarify that.<br />
<br />
=== 666 ===<br />
https://github.com/w3c/wcag21/issues/666<br />
(Lisa) Thank you for your feedback. We agree that the wording "a publicly available vocabulary" is problematic. It has been changed in the latest version.<br />
<br />
===683===<br />
https://github.com/w3c/wcag21/issues/683<br />
<br />
Thank you for the comment. It is too late to address these changes, and the changing of existing SC was out of scope for WCAG 2.1, but we will mark this issue with the "defer" label to ensure it is considered at an appropriate future time.<br />
<br />
===684===<br />
https://github.com/w3c/wcag21/issues/684<br />
<br />
Proposed response:<br />
We acknowledge your considered feedback and stance on the SC 1.3.4, however many in the working group feel that this important success criterion is a part of a suite that can create a cohesive personalisation matrix that can be built upon in the future, and with SC 1.3.4 and the now-reduced requirements there are implementations that support this SC. For SC 1.3.5, the SC will be listed as "at risk" in order to establish whether a sufficient level of implementations exist. This work can be continued either within WCAG 2.2 or even in other fora but many in the group support these SC and inclusion within WCAG 2.1.<br />
<br />
=== 687 ===<br />
https://github.com/w3c/wcag21/issues/687<br />
Thank you for the comment. The Working Group was not able to reach consensus on Target Size, and as a result the Target Size (SC) is now removed from the Editor's Draft. The Target Size (Enhanced) SC at AAA will be renamed to "Target Size".<br />
<br />
=== 691 ===<br />
<br />
https://github.com/w3c/wcag21/issues/691<br />
<br />
Thank you for your comment. We have introduced and modified the definition in the time since the last Working Draft. Your comment is not on the last Working Draft but on the editor's draft.<br />
<br />
=== 693 ===<br />
<br />
https://github.com/w3c/wcag21/issues/693<br />
<br />
Thank you for your comment. We have removed the definition that included the "publicly available vocabulary" wording.<br />
<br />
=== 694 ===<br />
<br />
https://github.com/w3c/wcag21/issues/694<br />
<br />
Thank you for your comment. We will mark this issue with the "implementation follow up" label for work in the understanding document.<br />
<br />
=== 698 ===<br />
https://github.com/w3c/wcag21/issues/698<br />
<br />
Thank you for the comment. The language of the SC has changed substantially and we believe that it addresses your concerns.<br />
<br />
=== 700 ===<br />
https://github.com/w3c/wcag21/issues/700<br />
<br />
Proposed response:<br />
<br />
Thank you for the comment. The WG used the discussion in this issue to inform the development of this SC. Please review the current version of the SC in the editor's draft.<br />
<br />
=== 701 ===<br />
https://github.com/w3c/wcag21/issues/701<br />
<br />
Proposed response:<br />
<br />
Thank you for the comment. The Working Group was not able to reach consensus on Target Size, and as a result the Target Size (SC) is now removed from the Editor's Draft. The Target Size (Enhanced) SC at AAA will be renamed to "Target Size".<br />
<br />
=== 702 ===<br />
https://github.com/w3c/wcag21/issues/702<br />
<br />
Proposed response:<br />
<br />
Thank you for the comment. The Working Group has elected to retain the "user agent control" exception, but is offering a AAA version of Target Size.<br />
<br />
=== 703 ===<br />
https://github.com/w3c/wcag21/issues/703<br />
<br />
Proposed response:<br />
<br />
Thank you for the comment. The WG did not decide to add a definition for input modalities as both "input" and "modalities" are used in WCAG 2.0, so it is important to continue to use these terms in the conventional ways rather than potentially redefine the terms.<br />
<br />
===704===<br />
https://github.com/w3c/wcag21/issues/704<br />
<br />
Proposed response:<br />
<br />
This SC is focused on motion, but we will mark this comment as "defer" to ensure it is review an an appropriate time for future consideration.<br />
<br />
===705===<br />
https://github.com/w3c/wcag21/issues/705<br />
<br />
Thank you for the comment. We will clarify this in the understanding documents.<br />
<br />
===706===<br />
https://github.com/w3c/wcag21/issues/706<br />
<br />
Proposed response:<br />
<br />
Thank you for the comment. The Working Group has not made changes to address your points but these may be possible to address through editorial changes in CR.<br />
<br />
===707===<br />
https://github.com/w3c/wcag21/issues/707<br />
<br />
Proposed response:<br />
<br />
> This SC seems very complicated. Is it practical for implementation at present? How would it be satisfied?<br />
<br />
The SC has changed in ways for which implementations already exist, using the autocomplete/autofill features in browsers. <br />
<br />
> Will the purposes in 7.1/7.2 be translated into languages other than EN?<br />
<br />
This will depend on translations of the HTML 5.2 specification.<br />
<br />
> Will these be implemented in ARIA?<br />
<br />
That will depend on the ARIA personalization work, but we expect that they will.<br />
<br />
> Which semantic schemas are user agents and assistive tech expected to recognise?<br />
<br />
The SC has changed in ways for which implementations already exist, using the autocomplete/autofill features in browsers. <br />
<br />
> Some phrases are very similar, particularly sign in/sign up/sign out. Will users appreciate the difference?<br />
<br />
This is no longer an issue with the new wording.<br />
<br />
> How granular should markup be for multi-field inputs such as address?<br />
<br />
Developers will follow the guidance for the autofill meanings in the HTML 5.2 spec.<br />
<br />
> "Credit card" appears twice in 7.2.<br />
<br />
This is no longer an issue with the new wording.<br />
<br />
> "Credit card" maps to an element containing multiple inputs? Or is it applied to every credit-card related input individually?<br />
<br />
Developers will follow the guidance for the autofill meanings in the HTML 5.2 spec.<br />
<br />
> "URL" (7.2) - will users appreciate that this markup only relates to URLs related to themselves? Would it apply if a user was asked "Enter the URL of your favourite news website"?<br />
<br />
We will make sure to cover this in understanding but for the news website example it would not apply.<br />
<br />
> "Birthdate" (7.2) - Does it have to correspond to the user or does it apply to any birthdate (e.g. family members in genealogy, insurance, etc.)<br />
<br />
Only to the user.<br />
<br />
=== 708 ===<br />
https://github.com/w3c/wcag21/issues/708<br />
<br />
Proposed response:<br />
<br />
Thank you for the comment. The CSS pixel is defined and in the definition there is a reference to the CSS specification for additional information. We will also make sure to clarify this and provide examples in the Understanding document.<br />
<br />
=== 709 ===<br />
https://github.com/w3c/wcag21/issues/709<br />
<br />
Proposed response:<br />
<br />
Thank you for the comment. We are marking this with the "implementation follow up" label for work in the understanding documents.<br />
<br />
=== 710 ===<br />
https://github.com/w3c/wcag21/issues/710<br />
<br />
Proposed response: (from Laura)<br />
<br />
Thank you for the comment. As [https://github.com/w3c/wcag21/issues/710#issuecomment-357478610 Alastair stated], a [https://github.com/alastc/adaptation-scripts/blob/master/scripts/text-adaptation.js bookmarklet] and a [https://userstyles.org/ stylish plugin] exist. Alternatively the user CSS is:<br />
<br />
* {<br />
line-height: 1.5 !important;<br />
}<br />
p {<br />
margin-bottom: 2em !important;<br />
}<br />
* {<br />
letter-spacing: 0.12em !important;<br />
}<br />
* {<br />
word-spacing: 0.16em !important;<br />
}<br />
<br />
=== 714 ===<br />
https://github.com/w3c/wcag21/issues/714<br />
<br />
Thank you for the comment. We have changed the text of the SC significantly, and removed the definition. We believe that these changes address your concerns.<br />
<br />
=== 715 ===<br />
https://github.com/w3c/wcag21/issues/715 (Answer by Detlev)<br />
<br />
Thank you for your comment. The text of SC 2.5.1 Pointer Gestures focuses on the need for alternatives to path-based or multipoint gestures. The Understanding text makes it clear that this in no way restricts authors from implementing complex gestures. It states explicitly: "When they implement complex multi-point or path-based gestures, they should ensure that the functionality can also be operated via single-point activation." This also applies to pinch-to-zoom gestures. They can and should be supported but another way to zoom content should be available (e.g., appropriately labelled [+] and [-] icons).<br />
<br />
As to panning with two fingers, the most frequent implementation of Google maps included on a web page offers an alternative in that a shift of the visible section can also be achieved by zooming out via the [-] button and then zooming in on any particular location via double tapping, a gesture which is included in single pointer. This is certainly more cumbersome and can be tricky if the target is near the edge of the visible map section, but arguably it would qualify as alternative.<br />
<br />
=== 716 ===<br />
<br />
https://github.com/w3c/wcag21/issues/716<br />
<br />
Thank you for your comment.<br />
<br />
> 1. Does every form-submission need an ‘un-submit’? (seems impractical)<br />
<br />
No, the SC states that only 1 of the 4 conditions must be true (and typically **only** one will be true). By far, the easiest way to pass this for a single click operation, as with most form submissions, is via the first possibility of no down-event. The native user agent behavior of a button is to only fire on the up-event. If, for example, the form could be submitted after a drag and drop, then a mechanism to abort could simply be a dialog asking "Are you sure you want to submit this?". The distinction is that an abort would cancel the function before it executes whereas an undo would reverse it after the fact.<br />
<br />
> 2. In Understanding, more guidance is needed about ‘Abort or Undo’<br />
<br />
Yes, we agree. The Understanding document reflects a slightly older version of this SC and will be updated in the coming months. In the meantime, a brief explanation for the Abort or Undo possibility is to allow for operations which must use the down-event, such as drag and drop or other gestures, to satisfy the criterion. By simply providing an abort possibility (e.g. via a confirmation dialog) or the ability to undo the action, users are afforded a measure to fix accidents for these types of events. Please see issue #380 for some additional details on this criterion's latest revision.<br />
<br />
=== 717 ===<br />
<br />
https://github.com/w3c/wcag21/issues/717 (Answer by Detlev)<br />
<br />
Thank you for your comment. We address the two issues you are raising in turn.<br />
<br />
1. Layman's definition of CSS Pixel: <br />
<br />
A definition of 'CSS pixel' exists in the WCAG 2.1 draft:<br />
https://www.w3.org/TR/WCAG21/#dfn-css-pixels <br />
<br />
The concept of CSS pixel is unfortunately not easily explained in lay terms. We believe that for people implementing or testing the SC, the definition needs to be technically precise. <br />
<br />
Due to the wide range of physical screen resolutions and device-reported (virtual) resolutions, measuring target size is only reliably possible by reference to CSS pixel dimensions. There is free software available to measure target sizes on screen, for example, "A ruler for Windows" http://www.arulerforwindows.com/index.html<br />
https://www.w3.org/TR/WCAG21/#dfn-css-pixels<br />
<br />
To address your concern, we suggest to add the following introductionary sentence: <br />
<br />
"CSS pixel is a concept that separates the visible area, or pitch, of a CSS pixel from the actual physical screen pixels used to represent it. This allows for an objective test across devices rather than tests which are completely dependent on the end user device, of which the author has no knowledge or control."<br />
<br />
2. Inline target loophole<br />
<br />
Several public and member comments to drafts of WCAG 2.1 have indicated that the application of the target size requirement to inline text targets would have a significant impact on screen layout, especially as adjacent lines would need a wide line spacing or a large text size if they are to meet the requirement. This can negatively impact usability as it would reduce the amount of text visible at the same time. The WG therefore decided to exempt targets in inline text .<br />
<br />
=== 718 ===<br />
https://github.com/w3c/wcag21/issues/718<br />
<br />
Thank you for the feedback. We do not believe that this SC conflicts with other SC, and we will mark this issue with the "implementation follow up" label to address the other parts of your comment in Understanding.<br />
<br />
=== 719 ===<br />
https://github.com/w3c/wcag21/issues/719<br />
<br />
Thank you for the feedback. 1.3.4 is offered at AA in the latest draft.<br />
<br />
=== 720 ===<br />
https://github.com/w3c/wcag21/issues/720<br />
<br />
Thank you for the comment. At this point, there is a strong likelihood that 1.3.4 will be in the WCAG 2.1 recommendation, but focused only on purposes for input elements.<br />
<br />
=== 721 ===<br />
https://github.com/w3c/wcag21/issues/721<br />
<br />
(Detlev) This has RNIB comments to many SCs in one issue.<br />
<br />
Proposed responses https://www.w3.org/WAI/GL/wiki/Draft_Response_issue_721<br />
<br />
=== 722 ===<br />
https://github.com/w3c/wcag21/issues/722<br />
<br />
Thank you for your comment. The Working Group came to a different conclusion, including others from your organization. We hope to gain further data to support this change in the implementation testing during CR.<br />
<br />
<br />
=== 723 ===<br />
https://github.com/w3c/wcag21/issues/723<br />
<br />
Thank you for your comment. The updated SC now addresses both of your concerns as the list of link and button purposes has been removed and the input purposes are based on the HTML 5.2 autofill values.<br />
<br />
=== 724 ===<br />
https://github.com/w3c/wcag21/issues/724<br />
<br />
Thank you for your comment. The SC was not designed to account for situations where a label is not presented as text. The scenario you describe is worth considering for a future release, so we will mark this issue as "defer" to ensure that it is reviewed at an appropriate time.<br />
<br />
===736===<br />
https://github.com/w3c/wcag21/issues/736<br />
<br />
Proposed response: https://www.w3.org/WAI/GL/wiki/Draft_Response_issue_736<br />
<br />
<br />
== Issues that have been addressed ==<br />
<br />
=== 150 ===<br />
https://github.com/w3c/wcag21/issues/150 Assigned to Goodwitch:<br />
<br />
Proposed Response (by Goodwitch): Thanks for your comment, Scott. We think we have addressed your concerns in the latest version of this SC and the updated Understanding Document. <br />
<br />
SC Changes - In the first draft of WCAG 2.1 (20170228) the proposed SC text for Graphics Contrast had used "essential" in both the positive and in the negative (as part of an exception). Based on your feedback (and feedback from others) we refined this SC text to only use "essential" as part of the exception. This language is parallel to the way "essential" is used in WCAG 2.0 SC 1.4.5 Images of Text. <br />
<br />
Understanding Changes - Examples to clarify this SC have been created in the draft understanding document that is published here https://rawgit.com/w3c/wcag21/graphics-contrast/understanding/21/graphics-contrast.html More examples and sufficient techniques will continue to be added to further enhance understandability and consistency in testing.<br />
<br />
===162===<br />
https://github.com/w3c/wcag21/issues/162<br />
<br />
Thank you for the comment. The Working Group will add content to the Understanding document as indicated in the issue responses. We will also mark this issue as "defer" to ensure that it is reviewed for more comprehensive changes in the Silver timeframe.<br />
<br />
===211===<br />
https://github.com/w3c/wcag21/issues/211<br />
<br />
Proposed response: https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues_211<br />
<br />
=== 260 ===<br />
https://github.com/w3c/wcag21/issues/260 <br />
<br />
Proposed response (from AWK):<br />
Thank you for your comment. Since your comment was logged we have changed the SC and believe that the new SC language (see in editor's draft: http://rawgit.com/w3c/wcag21/master/guidelines/index.html) addresses your concerns.<br />
<br />
=== 282 ===<br />
https://github.com/w3c/wcag21/issues/282<br />
<br />
Proposed response (from AlastairC):<br />
Thank you for your comment. Since your comment was logged the SC has changed significantly. Relevant changes include: The combination of concepts for 'Graphical Objects' and 'Required for understanding' which allow for a more granular testing approach, and they allow for small overlaps. It means there are many more options in terms of colours and design options. Also, the level of contrast has been reduced to 3:1 across situations. There are examples included in the understanding document, and more will be added. <br />
<br />
The Low vision task force has consulted with several researchers in the area, and while there is little direct research, their view was that the contrast level should be similar to reading text. However, for simplicity and feasibility the TF accepted the reduction to 3:1.<br />
<br />
=== 261 ===<br />
https://github.com/w3c/wcag21/issues/261 <br />
<br />
Proposed response (from AWK):<br />
Thank you for your comment. Since your comment was logged we have changed the SC and definition of target and we believe that your concerns are addressed. First, we are changing the first sentence of the definition to:<br />
<br />
Region of the display that will accept a pointer action, such as the interactive area of a user interface component.<br />
<br />
Second, regarding the concern about inline content such as footnotes, we now have an exception for links in a sentence or block of text.<br />
<br />
We hope that these address your concerns.<br />
<br />
<br />
=== 408 ===<br />
https://github.com/w3c/wcag21/issues/408<br />
<br />
Proposed Response (by AWK): Thank you for the comment. The use of "essential" in WCAG 2.1 is needed in some of the new SC as a way to convey an exception for content that must be presented in a specific manner and it is useful to make consistent use of the defined term for this purpose. In the SC identified the term essential refers to the specific way a graphic is presented, rather than the graphic itself being essential. We will clarify this in the understanding document.<br />
<br />
"Essential" is a defined term in WCAG, meaning "if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform".<br />
<br />
=== 520 ===<br />
https://github.com/w3c/wcag21/issues/520<br />
<br />
Proposed Response (by AWK & David MacDonald): Thank you for the comment.<br />
<br />
You make four main points:<br />
# The WCAG development process excludes people with intellectual or learning disabilities<br />
# Request for three new Success Criteria and a glossary item<br />
#* Navigation to plain language summary<br />
#* Plain language summary<br />
#* Plain language summary of main pages<br />
# Request for modification of SC 3.1.2<br />
# WCAG 2.1 doesn’t include measures for people with intellectual and learning disabilities<br />
<br />
It has been very important to the Working Group that people with various types of cognitive disabilities are included in the work of the group. We formed a task force for cognitive accessibility and welcomed many new members into the working group, many of whom either have some type of cognitive disability or work regularly on the topic. There is no question that the process of developing a specification with a group of almost 100 people providing input can be taxing due to the volume of email, wiki page updates, and spec updates that take place, but the W3C and the Working Group are committed to supporting the needs of any group members to help ensure that it is possible for anyone to participate to the greatest extent possible. Still, we recognize that there is always room for improvement and are open to any suggestions you may have. Although our COGA task force did a significant amount of [https://www.w3.org/TR/coga-user-research/ background research], and an extensive [https://www.w3.org/TR/2017/WD-coga-gap-analysis-20171207/ Gap Analysis], it appears that a Success Criteria for a Plain Language Summary as found in your comment was not proposed by any stakeholders in the timeframe for WCAG 2.1. However, there is a proposed Success Criteria called [https://www.w3.org/TR/WCAG21/#identify-common-purpose Identify Common Purpose] which may allow personalization and simplification of interfaces.<br />
<br />
Regarding the inclusion of requirements for people with intellectual and learning disabilities, while we agree that the set of Success Criteria does not address every possible improvement that end users might benefit from, there are substantial challenges to ensure they meet the following acceptance criteria for Success Criteria both in WCAG 2.0 and 2.1:<br />
<br />
* Be testable through automated or manual processes.<br />
* Apply to all content (including many human languages - internationalization) unless preconditions for the application of the success criteria are explicitly identified.<br />
* Apply across technologies to the greatest extent possible. (Technology-specific issues should usually be addressed in Techniques.)<br />
* Have Success Techniques which demonstrate that each Success Criterion is implementable, using readily-available formats, user agents, and assistive technologies.<br />
See: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria. <br />
<br />
These are some of the core requirements for Success Criteria that are very important but do set a challenging bar for new criteria to meet. If Success Criteria are included that do not meet these requirements there is a strong risk that WCAG 2.1 might not gain consensus or might not be adopted. Of the currently 18 new Success Criteria, approximately half are viewed as providing some benefit for users with cognitive disabilities. <br />
<br />
We should also mention that WCAG 2.0 [http://www.davidmacd.com/blog/wcag-for-low-vision-cognitive-disabilites.html provides important help for people with cognitive and learning disabilities]. We hope that there will be significant advances in Assistive Technology for people with cognitive and learning disabilities in the future, which may facilitate further WCAG requirements upon authors and leverage more of the existing requirements.<br />
<br />
==== Suggested new Success Criteria "Navigation to plain language summary" ====<br />
<br />
The deadline for introducing new Success Criteria closed over the summer as a result of the tight Working Group Charter timeline. However, we will mark this issue with a label (“defer”) to ensure that we can review these at the right time when we are able to review new proposals. This also impacts the suggestion for a definition since that definition is related to the proposed new criteria.<br />
<br />
We can provide it to the Cognitive Task Force (COGA) for consideration in a future version. It would impact the most important part of most web template designs and we expect there would be significant response from industry, so any objective research and studies your team can provide may help the COGA team with justifying this UI requirement universally across all web sites may be helpful.<br />
<br />
==== The suggested Amendment Success Criterion 3.1.2 Language of Parts ====<br />
<br />
Amending existing WCAG 2.0 Success Criteria is not permitted for WCAG 2.1 development, so in addition to the timeline consideration above, this suggestion would not be possible during this round of development.<br />
<br />
We can provide it to the Cognitive Task Force (COGA) for future consideration. In addition to the concerns about impact on site design, there is currently no assistive technology we know of that could make use of programmatically determined summaries in plain language. We suggest that this be demonstrated to the COGA team.<br />
<br />
==== Insert new Criterion 3.1.7: Plain Language Summary of site ====<br />
<br />
We extensively examined several proposals for plain language requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for an Success Criteria that could apply to "all content", and also there was some concern about requirements for freedom of expression. Regarding applying a plain language to a summary, these concerns may or may not be able to be overcome. <br />
<br />
We can provide it to the Cognitive Task Force (COGA) for future consideration.<br />
<br />
==== Ensure the summary page is clearly identified by a non-verbal icon. ====<br />
<br />
In addition to the timeline considerations above, we have had trouble gaining consensus on specific icons in the past. There are different cultures and different environments which may or may not approve of a particular icon design. We know of no such internationally recognized icon. WCAG strives to apply across the entire web to all countries and all languages, and so we'd like to hear about how we can ensure that a requirement for an icon could meet this need.<br />
<br />
==== Insert new term in Glossary ====<br />
We extensively examined several proposals for "plain language" requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for a Success Criteria. Also, there was some concern about requirements for freedom of expression.<br />
<br />
There is a strong possibility that there are ideas that the Working Group has simply not considered yet. Fortunately, the Working Group is committed to updating the specification far more rapidly than has been done in the past (targeting every 2 years), so these ideas and others will be able to be considered more fully in the near future.<br />
<br />
=== 601 ===<br />
https://github.com/w3c/wcag21/issues/601 Assigned to JOC:<br />
<br />
Proposed Response (by JOC): <br />
Thank you for your observation. We believe that you refer to section 7.1 Common Control Purposes" https://www.w3.org/TR/WCAG21/#control-purposes. The Working Group will add a item to represent "skip to" links.<br />
<br />
<br />
=== 602 ===<br />
https://github.com/w3c/wcag21/issues/602<br />
<br />
Proposed Response (by AWK): <br />
The list of purposes is explicitly not requiring that the author use the specific text to identify a purpose, so adding the requirement to use the listed name is different than what we intended. For example, the "Table of Contents" purpose may be referenced using a different term depending on whether the author is incorporating metadata from one schema or another - one schema might use "toc" and another might use "tableOfContents" but as long as they are aligned with the purpose expressed in the list (and as long as there is accessibility support) either would be sufficient.<br />
<br />
=== 605 === <br />
https://github.com/w3c/wcag21/issues/605 Assigned to JOC:<br />
<br />
Proposed response (by Mike Gower):<br />
<br />
The initial goal of this SC was broader in scope but various considerations were identified which led the authors to keep the scope contained. Instead the intention is to list Best Practices and Advisory Techniques which could address broader Changes of Content. To that end, the SC language will not be changed.<br />
<br />
Here are specific responses to some of the points raised in the issue:<br />
<br />
> addresses the implementation of status messages, but doesn't say there needs to be a status message (essentially you can pass by not having a status message)<br />
<br />
That is by design. WCAG has a history of defining content requirements when the content is ''present''.<br />
<br />
Any attempt to make status messages a requirement will inevitably lead to poor implementations that make applications unusable by screen reader users -- the exact opposite of the goal. It was felt that significant scrutiny is given by designers to information they add to the UI. Restricting the SC to cover such information, where it does not alter a user's context (no change of context), seemed like a way to ensure messages were appropriate and limited.<br />
<br />
> indicates that the info be presented by AT without receiving focus<br />
<br />
That is not exactly what the SC is saying. It defines status messages as items that do not take focus (change of content without being a change of context), and _then_ makes requirements where such items exist. The SC does not restrict messages from being displayed in a dialog, for example. Such a message is a change of context and so does not meet the definition of a status message, and so is not covered by it (being instead covered by 4.1.2).<br />
<br />
> The need (and reasonable implementation) is not limited to markup languages... An interactive book implemented in Swift or Objective-C for iOS can certainly easily provide notification through AT, for example.<br />
<br />
The working group spent considerable time debating removing the markup language restriction. In the end, the group felt there is not enough research, evidence or best practices to apply this to other technologies. WCAG 2.0 and 2.1 apply to content at a URL. However, we'd be glad to have you propose a technique for how to apply this to other technologies that we could add as a best practice for those who may be trying to apply WCAG to content not at a URL.<br />
<br />
> If a change of content causes new content or functionality to appear on the screen, at least one of the following is true:<br />
<br />
We believe this effectively means "For each change of content at least one of the following is true:" We had several iterations with a similar approach to this, covering similar scenarios. All were abandoned due to nuances of implementation or testing. Some of those have been identified below.<br />
<br />
> The new content appears directly after the control that triggers it in the reading order.<br />
<br />
If the new content is a user interface control, this will likely be detected by screen readers. (Although issues with latency can cause focus issues; for example, where the user's act of leaving a control triggers a change, the user's focus may move to the next existing item before coding updates the DOM, thus the user bypasses the new control.)<br />
<br />
But what if the new content is an element that does not take focus? If the screen reader user has previously perused the page and is now navigating by pressing Tab, how is the screen reader user to know the new information exists? Since an author could use this bullet to bypass notifying users (the first bullet), it seems to lose a key accomplishment of the current SC language.<br />
<br />
> For content that is updated on a regular basis, or is updated so frequently that status messages may be disruptive, the user is advised of the type and frequency of updates (e.g. through a section heading or label)<br />
<br />
These "regular basis" and "disruptive" parameters would have to be defined in a way that was testable. The manner of advising the user would itself be quite difficult to establish in language that ensured it was testable. There is danger that this would be poorly implemented and would degrade the experience for a screen reader user. Perhaps in future iterations of WCAG we can find standardized and testable ways of notifying users of content that updates frequently without this risk of interfering with their experience.<br />
<br />
Some examples of interactions which may not be covered/considered by your alternative proposal:<br />
<br />
- chat clients and other dynamic interactive content where the content changes are related to the primary page but not ultimately initiated by the user<br />
<br />
- twitter feeds and other updating content whose frequency of change and nature of content changes can vary markedly based on parameters beyond the author's control or ability to predict accurately.<br />
<br />
- existing content that is altered rather than content that is added (e.g., the items in a select is updated based on a user's chosen value in a control, such as the choice of a country updating the values in the "State/province" select)<br />
<br />
<br />
=== 608 ===<br />
https://github.com/w3c/wcag21/issues/608<br />
<br />
Proposed response (from AWK): <br />
<br />
We are closing this issue as it is redundant to issue #609.<br />
<br />
=== 609 ===<br />
https://github.com/w3c/wcag21/issues/609<br />
<br />
Proposed response (from AWK): <br />
<br />
We are happy to make the changes from "which" to "that" for the WCAG 2.1 SC, glossary definitions, and within the "common purposes" section in order to make the guidelines more clear. We cannot change all of the suggested items, including boilerplate text and text within WCAG 2.0 glossary items. The main change needed to make it clear that sentence parts now starting with "which" are restrictive clauses is dropping the comma. The comma will be removed in cases where we need restrictive clauses.<br />
<br />
=== 613 ===<br />
https://github.com/w3c/wcag21/issues/613<br />
<br />
Editorial. Closed by AWK<br />
<br />
=== 614 ===<br />
https://github.com/w3c/wcag21/issues/614<br />
<br />
Editorial. Fixed and closed by AWK<br />
<br />
=== 615 ===<br />
https://github.com/w3c/wcag21/issues/615<br />
<br />
Editorial. Fixed and closed by AWK<br />
<br />
=== 616 ===<br />
https://github.com/w3c/wcag21/issues/616<br />
<br />
Proposed response (from AWK & AlastairC):<br />
<br />
The Working Group made the decision to not modify existing SC from WCAG 2.0, which is why these requirements are in a new SC. If you have any suggestions for an SC title that would address your concerns, please suggest it. <br />
<br />
From the suggestions in the thread, "Non-text contrast" got the most support. As a term it is wider in scope than the criteria itself, but it aligns with WCAG 2.0 reasonably well. That change has been made in a new draft.<br />
<br />
=== 617 ===<br />
https://github.com/w3c/wcag21/issues/617<br />
<br />
Proposed response (from AWK):<br />
<br />
We agree that there is a potential for confusion, and have made a change to the SC text to read:<br />
<br />
"User Interface Components: Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;"<br />
<br />
=== 618 ===<br />
https://github.com/w3c/wcag21/issues/618<br />
<br />
Proposed response (by AWK): <br />
<br />
The first two items in your comment are editorial and have been changed as suggested. Regarding the comment about the use of "social Security" we will change the SC text to use your suggestion of "National identification number" as follows:<br />
<br />
"Authentication process involves basic personal identification information to which the user has easy access, such as name, address, email address, and National identification number."<br />
<br />
=== 619 ===<br />
https://github.com/w3c/wcag21/issues/619 Assigned to JOC and Detlev<br />
<br />
Proposed WG response (Detlev)<br />
<br />
Thank you for your suggestion. We agree that for interactions that include activation by positioning the device in a particular geographic location (your virtual fountain example), the requirement to provide alternative means of input does not apply. However, pointing a phone in the direction of a virtual location would still be a problem for a user with a motor impairment or a mounted device, so this would not negate the need for keyboard/pointer-accessible alternative modes of input. We believe the provision of alternative accommodations like the one you suggest could be included in a future SC focused on the use scenario of AR / Vr applications, and we are marking this issue as "defer" to ensure that it is reviewed at an appropriate time.<br />
<br />
=== 622 ===<br />
https://github.com/w3c/wcag21/issues/622 Assigned to Detlev<br />
<br />
Proposed response (Detlev)<br />
<br />
Thank you for your comment. You describe usage scenarios where input happens not via a particular user motion, but via the position or orientation of the device. This issue is likely to become more important with the spread or AR / VR use scenarios. However, we believe it can be separated from the use case of motion actuation where motion is relative to the device and the exact position (e.g. on the z-axis, distance to ground) seems less relevant. The case of orientation (no position lock unless by user choice, content adapts to user-chosen orientation) seems already addressed by the SC 2.6.2 Orientation.<br />
<br />
You raise an interesting issue when you talk of alternatives other than user interface controls that still use motion but adapt in other ways (e.g., by lowering AR / VR objects for wheelchair users), motivated by the aim to not negate the full experience for wheelchair users (and many others). While different accommodations are certainly useful and should be encouraged, they would not negate the need for a means of input that works with keyboard and pointer interfaces. (An analogy might be sign language: Having a sign language version of a video talk is great, but it does not negate the requirement for captions.) You make the point that in the future, the availability of those other accommodations might be the difference between participation and exclusion (through exceptions) from entire categories of software. Requirements for alternative accommodations would be a good subject for a future SC as these technologies become more mature and widespread. We are open to suggestions to include additional techniques as optional best practices in the understanding document. Can you provide a description and examples that could be used?<br />
<br />
<br />
=== 630 ===<br />
https://github.com/w3c/wcag21/issues/630 (Answer by Mike Gower)<br />
<br />
> I find this really confusing and would like some examples to illustrate these criteria.<br />
<br />
The Understanding document is in the process of being updated, and will offer examples and clarity. The current draft provides some explanation and [Examples](https://w3c.github.io/wcag21/understanding/21/content-on-hover-or-focus.html)<br />
<br />
> If there must be a mechanism to dismiss content without moving the pointer or keyboard focus, what might that look like? <br />
<br />
The normal mechanism for dismissing any kind of overlay is the Escape key; if that is implemented, this first bulleted requirement is met. Note that the wording of the SC does not prevent an author from adding in a mouse-equivalent affordance for this (such as simply moving away from the trigger/new content or hitting a close button displayed as a ‘x’ in the upper right corner of the overlay). The SC simply requires that there be a method that does not involve moving the mouse.<br />
<br />
> Most mechanisms to dismiss content ask that the user click on a button, which requires moving the pointer or keyboard focus.<br />
<br />
> What is the benefit to being able to hover over additional content that only appears on hover?<br />
<br />
The specific reason for a requirement to dismiss the on-hover overlay without moving the mouse, involves low vision users or users with reduced fine motor skills. Low vision users with a substantial level of magnification have a limited viewport. If they accidentally trigger new content with hover, they need to be able to dismiss that new content without losing their current point of regard. Otherwise, they are put in the situation where they must move their entire viewport away from the location they wished to interact with in order to dismiss the new unwanted content. After re-orienting themselves back again after the new content disappears, they then may accidentally trigger the hover again, repeating the same experience. Similarly, a user who cannot easily control the mouse and so is more prone to accidental triggering of on-hover content, needs a method of easily dismissing that is not mouse based.<br />
<br />
As will be made clear in the Understanding document, this SC is not recommending or encouraging the use of On Hover or On Focus as the trigger for displaying new content. This is considered a poor interaction by many, since users may easily inadvertently trigger new content. However, where an author elects to employ On Hover as a trigger, this SC places requirements on the implementation which make the resulting experience more accessible.<br />
<br />
=== 644 ===<br />
https://github.com/w3c/wcag21/issues/644 (Assigned to Laura):<br />
<br />
Proposed response:<br />
<br />
Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:<br />
<br />
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."<br />
<br />
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.<br />
<br />
We will also clarify the applicability of this SC in the Understanding document.<br />
<br />
=== 656 ===<br />
https://github.com/w3c/wcag21/issues/656<br />
<br />
Proposed response (AC):<br />
Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:<br />
<br />
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."<br />
<br />
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.<br />
<br />
=== 671 ===<br />
https://github.com/w3c/wcag21/issues/671<br />
<br />
Proposed response: (from AWK)<br />
Thank you for your suggestion. We agree that the definition of target was hard to parse and needed updating. We have changed "touch action" to "pointer action" to cover all pointer input, not just touch. We have also simplified the text explaining that parts of a target covered by another target must be excluded in target size measurements. <br />
<br />
Pull request for revised definition of 'target': https://github.com/w3c/wcag21/pull/673<br />
<br />
=== 722 ===<br />
https://github.com/w3c/wcag21/issues/722<br />
<br />
Proposed response:<br />
Thank you for the comment. We will remove this note from the conformance section and address this topic in the Understanding document.<br />
<br />
Alternate proposed response:<br />
Thank you for the comment. This note is non-normative (as are all notes) but does represent the consensus view of the Working Group.<br />
<br />
===386===<br />
https://github.com/w3c/wcag21/issues/386<br />
<br />
Thank you for the comment. We have re-written the criterion to incorporate your suggestion. The updated SC can be viewed at: [link]<br />
<br />
===402===<br />
https://github.com/w3c/wcag21/issues/402<br />
<br />
Proposed response:<br />
<br />
Thank you for the comment. The SC has been changed to focus on currently supported attributes, so browsers support this across the board:<br />
https://caniuse.com/#feat=input-autocomplete-onoff<br />
(There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)<br />
<br />
This aspect alone is very helpful to some people with cognitive issues.<br />
<br />
For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already:<br />
Chrome extension: http://accessibility.athena-ict.com/personlization.shtml<br />
Script: https://github.com/ayelet-seeman/coga.personalisation<br />
Website based implementation: https://a11y-resources.com/developer/coga-personalisation<br />
<br />
These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.<br />
<br />
Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.<br />
<br />
Given the user-need, and that this new version is far easier to implement, we hope that this addresses your concerns.<br />
<br />
===407===<br />
https://github.com/w3c/wcag21/issues/407<br />
<br />
Proposed response:<br />
<br />
Thank you for your comment. At times the Working Group uses phrases such as "content implemented using markup languages" as you note, and the reason is that is some cases the Working Group has determined that a certain SC applies to technologies with specific features. This may be because there are specific markup-related that need to be attended to, or it may be used as an exception because the working group is aware of a gap in support for non-markup technologies and in order to arrive at a consensus the language is used to narrow the scope of the criterion.<br />
<br />
In the current Editor's draft, "Text Spacing" and "Status Changes" are the only criteria remaining that employ this phrase, and in both the reason is that there is a gap in support for the requirements beyond HTML. We anticipate that this will change, and the Working Group will be able to update the criteria in response.<br />
<br />
=== 411 ===<br />
https://github.com/w3c/wcag21/issues/411<br />
<br />
Proposed response (from AlastairC):<br />
<br />
Thank you for your comment. The term graphical object was selected to be generic as it covers a wide range of parts of graphics. Defining the term object (beyond the current text or the dictionary definition) does not appear to help. However, the Understanding document does include a large section to provide context and examples, and that is being expanded.<br />
<br />
===541===<br />
https://github.com/w3c/wcag21/issues/541<br />
<br />
Proposed response:<br />
<br />
===544===<br />
https://github.com/w3c/wcag21/issues/544<br />
<br />
Proposed response:<br />
<br />
=== 586 === <br />
https://github.com/w3c/wcag21/issues/586<br />
<br />
Proposed response: Unfortunately, due to issues around the implementation and feasibility the purposes related to links and buttons have been removed, but the purposes related to form inputs were retained and expanded.<br />
We do intend to expand on this work in future, and would like to defer this comment for future work.<br />
<br />
=== 589 === <br />
https://github.com/w3c/wcag21/issues/589<br />
<br />
Proposed response (AWK):<br />
Thank you for your comment. We understand your concern about PDF/UA including requirements that are unrelated to reflow in a PDF document. The possible technique has not been drafted or approved, so we appreciate your feedback. It is important to point out that techniques are not required, but they are sufficient, so if a PDF/UA conforming document would always meet the reflow requirements, we could make a technique that clarified this connection, but we would undoubtedly include other techniques as well that would allow a PDF to meet the reflow SC without conforming to PDF/UA.<br />
<br />
Of course, as you indicate, to include a PDF/UA-related technique we would need to consider the testing questions you mention and more.<br />
<br />
We have work to do to ensure that the understanding and techniques documents are up to date and accurate, but it is worth mentioning that the plan moving forward is that the non-normative techniques and understanding documents will be able to be updated continuously in the event that new information or errors are identified.<br />
<br />
=== 590 === <br />
https://github.com/w3c/wcag21/issues/590<br />
<br />
Proposed response: <br />
While there are some privacy and security concerns with automatically filling in inputs (without the user wanting to), this is ultimately a user-agent/browser issue.<br />
The way to solve the issue is to make sure the user agrees to fields being populated (e.g. clicks a button in the browser interface), and avoid filling in hidden inputs.<br />
We can note the concern in the understanding document, but if change is needed it is up to the browsers and Web Platform working group to resolve.<br />
<br />
=== 598 === <br />
https://github.com/w3c/wcag21/issues/598<br />
Thank you for the comment. We intend to include PDF documents in the implementations for review. PDF documents can satisfy the WCAG definition for "web page", which is: "a non-embedded resource obtained from a single URI using HTTP plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent". This is the same reasoning used to include techniques for PDF for WCAG 2.0 in the past, and we will be looking to offer PDF techniques for WCAG 2.1 Success Criteria as well.<br />
<br />
=== 620 ===<br />
https://github.com/w3c/wcag21/issues/620 Related question asked by JOC, awaiting response and will then draft response: Assigned to JOC<br />
<br />
Proposed WG response (Detlev)<br />
<br />
Thank you for your comment. You propose to remove 'user motion' to exclude situations where the user is moving and the device just observing. The aim of the user motion part of the SC was to address motions like hand gestures that are observed by the camera or other sensors that can trigger certain events (such as forwarding a presentation, or panning a view). We have changed the SC text and the understanding text to clarify that 'user motion' means explicit actuation in the context of this SC. We have spelled out that scenarios where the user moves without explixitly actuating content (as in your your Leap Motion example) or where the device just observes without the user intentionally gesturing towards the device, are not in scope of this SC.<br />
<br />
We will mark this issue as "defer" to ensure that it is reviewed at an appropriate time in the future.<br />
<br />
=== 621 ===<br />
https://github.com/w3c/wcag21/issues/621<br />
<br />
Proposed response (Detlev)<br />
<br />
Thank you for your comment. You raise two issues - one is splitting device motion and user motion into separate SCs, the second is making us aware of a third type of similar functionality, that of motion / events in the field of view of the device (device is observing). We agree that this is a separate issue and potentially, a separate SC. In this SC, the issue is active, purposeful user input.<br />
We believe that the SC Motion Actuation addresses broadly issues common to two scenarios: firstly when the user moves the device itself (shaking, titling, panning) and secondly, when the user motions towards the device, i.e. carries out gestures aimed at actuating functions. We think that both scenarios can therefore be treated in one SC. <br />
<br />
We have updated the SC text and the Understanding text to clarify that input caused by the user moving through space, and situations where the device is observing anything other than purposeful user inputs, are not covered by this SC. <br />
<br />
As to your suggestion to separate out device and user motion, we will mark this issue as "defer" to ensure that it is reviewed at an appropriate time in the future.<br />
<br />
=== 624 ===<br />
https://github.com/w3c/wcag21/issues/624<br />
<br />
Proposed response: The wording has been significantly updated, we think this addresses the issue, it no longer includes the buttons aspect.<br />
<br />
=== 628 ===<br />
https://github.com/w3c/wcag21/issues/628<br />
<br />
=== 629 ===<br />
https://github.com/w3c/wcag21/issues/629<br />
<br />
The SC has been changed to focus on currently supported attributes, so browsers support this across the board:<br />
https://caniuse.com/#feat=input-autocomplete-onoff<br />
(There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)<br />
<br />
This aspect alone is very helpful to some people with cognitive issues.<br />
<br />
For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already:<br />
Chrome extension: http://accessibility.athena-ict.com/personlization.shtml<br />
Script: https://github.com/ayelet-seeman/coga.personalisation<br />
Website based implementation: https://a11y-resources.com/developer/coga-personalisation<br />
<br />
These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.<br />
<br />
Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.<br />
<br />
Given the user-need, and that this new version is far easier to implement, there does not seem to be an issue with including this SC at level AA.<br />
<br />
While there are some privacy and security concerns with automatically filling in inputs (without the user wanting to), this is ultimately a user-agent/browser issue.<br />
The way to solve the issue is to make sure the user agrees to fields being populated (e.g. clicks a button in the browser interface), and avoid filling in hidden inputs.<br />
We can note the concern in the understanding document, but if change is needed it is up to the browsers and Web Platform working group to resolve.<br />
<br />
The SC text and list of purposes has been updated so only the input aspects are used.<br />
<br />
=== 634 ===<br />
https://github.com/w3c/wcag21/issues/634<br />
<br />
Thanks for the comment. We agree that the definition needs to be clarified. We are changing the definition to:<br />
<br />
"Pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures"<br />
<br />
=== 635 ===<br />
https://github.com/w3c/wcag21/issues/635 (answer from Lisa)<br />
<br />
Proposed response:<br />
<br />
Thanks for the comment. The new SC text has resolved this issue.<br />
<br />
=== 637 ===<br />
https://github.com/w3c/wcag21/issues/637<br />
<br />
Thank you for the comment. We will add the notice as done in ARIA. Please note that these are the correct interpretations for these terms even without this sentence since the document indicates that it is governed by the process document and the process document makes this same claim.<br />
<br />
=== 649 ===<br />
https://github.com/w3c/wcag21/issues/649<br />
<br />
(AlastairC) Thank you for your comment. The working group appreciates that the changes between states should be obvious to people viewing the content. However, it is very difficult to craft a requirement that does not run into the issue of not having enough colours for a particular component. The focus of this success criteria is to cover the non-text parts of (active) UI components, but we will certainly consider expanding to explicitly cover the differentiation of states for UI components in future iterations.<br />
<br />
=== 650 ===<br />
https://github.com/w3c/wcag21/issues/650 . (Answer:David MacDonald)<br />
<br />
Thank you for your comment. Tabbed interfaces and similar selections, such as a drop-down box, that may cause additional content to become visible on focus/selection were not intended to be covered by this criterion. Rather, the criterion was designed for content that also becomes hidden when focus (or hover) is removed. We agree the criterion text did not reflect this well and made a change so that it now reads:<br />
<br />
> Where receiving and removing pointer hover or keyboard focus triggers additional content to become visible and hidden, respectively, the following are true: ...<br />
<br />
This scopes out tabbed interfaces because the removal of focus does not then hide the content because it is still selected. In this case, it might seem like the content is removed when the tab loses focus, but the content is actually changed when a different item receives the focus. We hope this addresses your concerns.<br />
<br />
Regarding techniques, the working group will be working hard on the supporting understanding and technique materials in the next few months.<br />
<br />
=== 653 ===<br />
https://github.com/w3c/wcag21/issues/653<br />
<br />
Proposed response: Same response as #672<br />
<br />
=== 654 ===<br />
https://github.com/w3c/wcag21/issues/654 <br />
<br />
Proposed response: <br />
<br />
The SC has been changed to focus on currently supported attributes, so browsers support this across the board:<br />
https://caniuse.com/#feat=input-autocomplete-onoff<br />
(There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)<br />
<br />
This aspect alone is very helpful to some people with cognitive issues.<br />
<br />
For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already:<br />
Chrome extension: http://accessibility.athena-ict.com/personlization.shtml<br />
Script: https://github.com/ayelet-seeman/coga.personalisation<br />
Website based implementation: https://a11y-resources.com/developer/coga-personalisation<br />
<br />
These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.<br />
<br />
Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.<br />
<br />
Given the user-need, and that this new version is far easier to implement, there does not seem to be an issue with including this SC at level AA.<br />
<br />
In the current proposal the list is based on something that browsers have already implemented, in future iterations of WCAG it is possible this will be separated.<br />
<br />
=== 655 ===<br />
https://github.com/w3c/wcag21/issues/655<br />
<br />
Thank you for your comment. The existing exception language was carefully worded with input from many working group members and is used in other draft criteria (Graphics Contrast and Target Size). The language you proposed does not seem to address the key technology-specific exception of the `title` attribute, because the author has full control of its existence. The distinction about the user agent is needed to identify that the author may not be able to control the visual styling or behavior on hover or focus, but they do control its existence.<br />
<br />
It may be possible to apply this to documents and software with the same intentions simply by re-interpreting the "user agent" in those cases. For example:<br />
<br />
* **Software:** If the user agent is the OS, then it gives exception to wherever the OS may generate tooltips or similar applicable content and the developer uses the default presentation or has no ability to change it.<br />
* **Documents:** If the authoring software is the user agent, then the exception is again given to hover or focus content that the document author cannot style.<br />
<br />
=== 657 and 677 and 685===<br />
https://github.com/w3c/wcag21/issues/657<br />
<br />
https://github.com/w3c/wcag21/issues/677<br />
<br />
https://github.com/w3c/wcag21/issues/685<br />
<br />
Proposed response (AWK):<br />
Thank you for your comment. These properties are defined in CSS and in typographical principals, and they adhere to the meaning used in CSS. We will modify the description for paragraph spacing to "spacing following paragraphs" instead of "spacing underneath paragraphs" to address the implicit western language bias in this item. We will also add the following exception to address cases such as in Japanese where word-spacing is not typically used.<br />
<br />
Exception: Human languages and scripts which do not make use of one or more of these text style properties in written text can conform using only the properties that are used.<br />
<br />
https://github.com/w3c/wcag21/pull/729<br />
<br />
=== 659 ===<br />
https://github.com/w3c/wcag21/issues/659<br />
<br />
Thank you for the comment. We have re-written the criterion to incorporate your suggestion. The updated SC can be viewed at: [link]<br />
<br />
=== 660 ===<br />
https://github.com/w3c/wcag21/issues/660<br />
<br />
Thank you for the comment. We have clarified the criterion to ensure that Space and Enter are not referred to incorrectly. You can view the updated criterion at: [link]<br />
<br />
=== 661 ===<br />
https://github.com/w3c/wcag21/issues/661<br />
<br />
Proposed response: Same response as #672<br />
<br />
=== 663 ===<br />
https://github.com/w3c/wcag21/issues/663 (Answer by Detlev)<br />
<br />
Thank you for your suggestion. We agree that your addition clarifies the text of SC 2.5.1 Pointer gestures. Path-based gestures are often carried out with a single pointer (as in drag-and-drop) so including an explicit reference ("...can be operated with a single pointer ''without a path-based gesture''") leaves less room for misunderstanding.<br />
<br />
=== 665 ===<br />
https://github.com/w3c/wcag21/issues/665<br />
<br />
Proposed response: The wording has been significantly updated, we think this addresses the issue.<br />
<br />
=== 667 ===<br />
https://github.com/w3c/wcag21/issues/667<br />
<br />
Thank you for the comment. We will adjust the SC text to make it easier to translate. The new SC text will read: <br />
<br />
"Users are warned of the duration of any user inactivity that could cause data loss, unless the data is preserved for more than 20 hours when the user does not take any actions."<br />
<br />
https://github.com/w3c/wcag21/pull/730<br />
<br />
=== 668 ===<br />
https://github.com/w3c/wcag21/issues/668<br />
<br />
Makoto to review latest ed draft.<br />
<br />
=== 669 ===<br />
https://github.com/w3c/wcag21/issues/669<br />
<br />
Thank you for the comment. In response to other issues (386, 659, 660) we have changed the structure of this SC. We believe that the new structure is clearer and hope it addresses your need for easier translation.<br />
<br />
=== 670 ===<br />
https://github.com/w3c/wcag21/issues/670<br />
<br />
Thank you for the comment. The specific phrasing of the SC is designed to match phrasing used in other SC. As a result, the WG needs to keep the SC text the same, except for adding "visually" to the end of the SC to provide additional clarity. See https://github.com/w3c/wcag21/pull/728/files for the specific change.<br />
<br />
=== 672 ===<br />
https://github.com/w3c/wcag21/issues/672<br />
<br />
Proposed response:<br />
The SC has been changed to focus on currently supported attributes, so browsers support this across the board:<br />
https://caniuse.com/#feat=input-autocomplete-onoff<br />
(There are some issues with browser implementations, but they do not appear to affect the autofill part of autocomplete.)<br />
<br />
This aspect alone is very helpful to some people with cognitive issues.<br />
<br />
For the aspect of adding icons for users (another goal of the SC) It is also worth noting that there are several implementations already:<br />
Chrome extension: http://accessibility.athena-ict.com/personlization.shtml<br />
Script: https://github.com/ayelet-seeman/coga.personalisation<br />
Website based implementation: https://a11y-resources.com/developer/coga-personalisation<br />
<br />
These are at early stages and have been using the COGA semantics spec, but these can be updated to cover the autofill attributes as well, while the other aspects mature.<br />
<br />
Overall, there is basic support for the proposal already, and people committed to expanding the functionality during the CR stage.<br />
<br />
Given the user-need, and that this new version is far easier to implement, there does not seem to be an issue with including this SC at level AA.<br />
<br />
=== 674 ===<br />
https://github.com/w3c/wcag21/issues/674<br />
<br />
Thank you for the comment. We have made changes to the criterion text to address the issue on vertical text.<br />
<br />
=== 676 ===<br />
https://github.com/w3c/wcag21/issues/676<br />
<br />
Thank you for the comment. We are updating the SC and modifying the first exception so that it starts with the description "Supported Interfaces", but the phrase "accessibility supported" is still used in the description, as follows:<br />
<br />
"The motion is used to operate functionality through an <a>accessibility supported</a> interface;"<br />
<br />
The Understanding document will be updated to reflect clearly that the intent is that where motion is used to operate an interface that has accessibility support (meaning that it has user agent and assistive technology support) that motion is exempt. For example, a user might use a head mouse system that operates using the camera in order to interface with the pointer/mouse interface would be exempted. We hope this addresses your concern.<br />
<br />
=== 677 ===<br />
https://github.com/w3c/wcag21/issues/677<br />
<br />
=== 680 ===<br />
https://github.com/w3c/wcag21/issues/680<br />
<br />
(From AlastairC): Thank you for your comment, as a member of the working group we assume there is no need to outline the CR process. Every SC should be tested, thank you for offering that support.<br />
<br />
Regarding high contrast mode, from some initial testing neither Windows (10 + Edge) or OSX (+Safari) help with perceiving graphics embedded into web pages, which highlights the importance of that part of this SC even more.<br />
<br />
Using a high-contrast mode could assist with the user-interface controls, but would be limited to standard controls, not custom ones created by authors.<br />
<br />
If there are user-agent factors that haven't been considered, please do comment on how those might impact the SC. However, it is worth nothing that the requirement from the Low Vision Task Force was that it should be a minimum standard for those without user-agent /OS support for contrast.<br />
<br />
=== 686 ===<br />
https://github.com/w3c/wcag21/issues/686<br />
<br />
(AlastairC) Thank you for your comment, the group agrees we should test where "graphics are reused in a multiplicity of contexts", do you have any examples you could share? <br />
<br />
The group appreciates that context is important for images, and that can change between pages. However, in order to meet the user-need it must focus on what is required for understanding. Utilising that concept also makes it more feasible to implement in general scenarios, as it is a wider exemption that pure-decoration.<br />
<br />
=== 688 ===<br />
https://github.com/w3c/wcag21/issues/688<br />
<br />
Thank you for your comment. We understand your desire to avoid imposing requirements on authors that might best be addressed by UA or AT, and believe that the current language's use of "a mechanism is available" helps ensure that solutions exist for end users in the near term but also provides a way for improvements in UA and AT support to remove this responsibility from authors. Today, with no AT or UA support, web applications like gmail can readily implement support (and have) for this SC. Since this SC is focused on developers who are implementing custom keyboard shortcuts, it is not expected that this SC will pose a challenge for most sites. We will clarify this in the understanding document to ensure that authors know how to evaluate whether UA and AT support exist and what techniques are available to meet this SC.<br />
<br />
===689===<br />
https://github.com/w3c/wcag21/issues/689<br />
<br />
Proposed response:<br />
Thank you for your comment. Unfortunately, due to issues around the implementation and feasibility the purposes related to links and buttons have been removed. We do intend to expand on this work in future, and would like to defer this comment for future work.<br />
<br />
<br />
=== 695 ===<br />
<br />
https://github.com/w3c/wcag21/issues/695<br />
<br />
Thank you for your comment. While the intent and requirement for the Hoverable condition has always been the same, we've struggled to state it as simply as possible in the SC. We have taken your suggestion to state it more plainly and edited it to read:<br />
<br />
> **Hoverable:** If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;<br />
<br />
=== 697 ===<br />
https://github.com/w3c/wcag21/issues/697<br />
<br />
(From AlastairC):<br />
Thank you for the comment. The working group agrees that the widening of scope to include all animation is not warranted at this time, and has scoped the SC text to motion animation, with an updated definition of animation, available at the pull request: https://github.com/w3c/wcag21/pull/738<br />
<br />
<br />
=== 711 ===<br />
<br />
https://github.com/w3c/wcag21/issues/711<br />
<br />
Thank you for your comment. While the intent and requirement for the Hoverable condition has always been the same, we've struggled to state it as simply as possible in the SC. We have taken your suggestion to state it more plainly and edited it to read:<br />
<br />
> **Hoverable:** If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Draft_Responses_to_Dec_WD_Issues&diff=9100Draft Responses to Dec WD Issues2018-01-11T16:16:31Z<p>Dmacdona: /* 520 */</p>
<hr />
<div>== This page contains draft responses to issues logged in GitHub ==<br />
Open issues: https://github.com/w3c/wcag21/labels/Dec%20WD%20Comment<br />
<br />
If your issue is not listed, please add it as a heading 3 and make sure to indicate who drafted the response. See below for examples to follow in terms of organization of the information.<br />
<br />
Please write the responses in a way that can be easily copied/pasted into the issue. For each issue the editors will add "Official WG response: Thank you for your comment." to the start, so it isn't necessary to include that in the response.<br />
<br />
When an item is approved by the WG it will be indicated in the heading.<br />
<br />
===162===<br />
https://github.com/w3c/wcag21/issues/162<br />
<br />
Thanks you for the comment. The Working Group will add content to the Understanding document as indicated in the issue responses. We will also mark this issue as "defer" to ensure that it is reviewed for more comprehensive changes in the Silver timeframe.<br />
<br />
===211===<br />
https://github.com/w3c/wcag21/issues/211<br />
<br />
Proposed response: https://www.w3.org/WAI/GL/wiki/Draft_Responses_to_Dec_WD_Issues_211<br />
<br />
=== 260 ===<br />
https://github.com/w3c/wcag21/issues/260 <br />
<br />
Proposed response (from AWK):<br />
Thank you for your comment. Since your comment was logged we have changed the SC and believe that the new SC language (see in editor's draft: http://rawgit.com/w3c/wcag21/master/guidelines/index.html) addresses your concerns.<br />
<br />
=== 261 ===<br />
https://github.com/w3c/wcag21/issues/261 <br />
<br />
Proposed response (from AWK):<br />
Thank you for your comment. Since your comment was logged we have changed the SC and definition of target and we believe that your concerns are addressed. First, we are changing the first sentence of the definition to:<br />
<br />
Region of the display that will accept a pointer action, such as the interactive area of a user interface component.<br />
<br />
Second, regarding the concern about inline content such as footnotes, we now have an exception for links in a sentence or block of text.<br />
<br />
We hope that these address your concerns.<br />
<br />
<br />
=== 408 ===<br />
https://github.com/w3c/wcag21/issues/408<br />
<br />
Proposed Response (by AWK): Thank you for the comment. The use of "essential" in WCAG 2.1 is needed in some of the new SC as a way to convey an exception for content that must be presented in a specific manner and it is useful to make consistent use of the defined term for this purpose. In the SC identified the term essential refers to the specific way a graphic is presented, rather than the graphic itself being essential. We will clarify this in the understanding document.<br />
<br />
"Essential" is a defined term in WCAG, meaning "if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform".<br />
<br />
=== 520 ===<br />
https://github.com/w3c/wcag21/issues/520<br />
<br />
Proposed Response (by AWK & David MacDonald): Thank you for the comment.<br />
<br />
You make four main points:<br />
# The WCAG development process excludes people with intellectual or learning disabilities<br />
# Request for three new Success Criteria and a glossary item<br />
#* Navigation to plain language summary<br />
#* Plain language summary<br />
#* Plain language summary of main pages<br />
# Request for modification of SC 3.1.2<br />
# WCAG 2.1 doesn’t include measures for people with intellectual and learning disabilities<br />
<br />
It has been very important to the Working Group that people with various types of cognitive disabilities are included in the work of the group. We formed a task force for cognitive accessibility and welcomed many new members into the working group, many of whom either have some type of cognitive disability or work regularly on the topic. There is no question that the process of developing a specification with a group of almost 100 people providing input can be taxing due to the volume of email, wiki page updates, and spec updates that take place, but the W3C and the Working Group are committed to supporting the needs of any group members to help ensure that it is possible for anyone to participate to the greatest extent possible. Still, we recognize that there is always room for improvement and are open to any suggestions you may have. Although our COGA task force did a significant amount of [https://www.w3.org/TR/coga-user-research/ background research], and an extensive [https://www.w3.org/TR/2017/WD-coga-gap-analysis-20171207/ Gap Analysis], it appears that a Success Criteria for a Plain Language Summary as found in your comment was not proposed by any stakeholders in the timeframe for WCAG 2.1. However, there is a proposed Success Criteria called [https://www.w3.org/TR/WCAG21/#identify-common-purpose Identify Common Purpose] which may allow personalization and simplification of interfaces.<br />
<br />
Regarding the inclusion of requirements for people with intellectual and learning disabilities, while we agree that the set of Success Criteria does not address every possible improvement that end users might benefit from, there are substantial challenges to ensure they meet the following acceptance criteria for Success Criteria both in WCAG 2.0 and 2.1:<br />
<br />
* Be testable through automated or manual processes.<br />
* Apply to all content (including many human languages - internationalization) unless preconditions for the application of the success criteria are explicitly identified.<br />
* Apply across technologies to the greatest extent possible. (Technology-specific issues should usually be addressed in Techniques.)<br />
* Have Success Techniques which demonstrate that each Success Criterion is implementable, using readily-available formats, user agents, and assistive technologies.<br />
See: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria. <br />
<br />
These are some of the core requirements for Success Criteria that are very important but do set a challenging bar for new criteria to meet. If Success Criteria are included that do not meet these requirements there is a strong risk that WCAG 2.1 might not gain consensus or might not be adopted. Of the currently 18 new Success Criteria, approximately half are viewed as providing some benefit for users with cognitive disabilities. <br />
<br />
We should also mention that WCAG 2.0 [http://www.davidmacd.com/blog/wcag-for-low-vision-cognitive-disabilites.html provides important help for people with cognitive and learning disabilities]. We hope that there will be significant advances in Assistive Technology for people with cognitive and learning disabilities in the future, which may facilitate further WCAG requirements upon authors and leverage more of the the existing requirements.<br />
<br />
==== Suggested new Success Criteria "Navigation to plain language summary" ====<br />
<br />
The deadline for introducing new Success Criteria closed over the summer as a result of the tight Working Group Charter timeline. However, we will mark this issue with a label (“defer”) to ensure that we can review these at the right time when we are able to review new proposals. This also impacts the suggestion for a definition since that definition is related to the proposed new criteria.<br />
<br />
We can provide it to the Cognitive Task Force (COGA) for consideration in a future version. It would impact the most important part of most web template designs and we expect there would be significant response from industry, so any objective research and studies your team can provide may help the COGA team with justifying this UI requirement universally across all web sites may be helpful.<br />
<br />
==== The suggested Amendment Success Criterion 3.1.2 Language of Parts ====<br />
<br />
Amending existing WCAG 2.0 Success Criteria is not permitted for WCAG 2.1 development, so in addition to the timeline consideration above, this suggestion would not be possible during this round of development.<br />
<br />
We can provide it to the Cognitive Task Force (COGA) for future consideration. In addition to the concerns about impact on site design, there is currently no assistive technology we know of that could make use of programmatically determined summaries in plain language. We suggest that this be demonstrated to the COGA team.<br />
<br />
==== Insert new Criterion 3.1.7: Plain Language Summary of site ====<br />
<br />
We extensively examined several proposals for plain language requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for an Success Criteria that could apply to "all content", and also there was some concern about requirements for freedom of expression. Regarding applying a plain language to a summary, these concerns may or may not be able to be overcome. <br />
<br />
We can provide it to the Cognitive Task Force (COGA) for future consideration.<br />
<br />
==== Ensure the summary page is clearly identified by a non-verbal icon. ====<br />
<br />
In addition to the timeline considerations above, we have had trouble gaining consensus on specific icons in the past. There are different cultures and different environments which may or may not approve of a particular icon design. We know of no such internationally recognized icon. WCAG strives to apply across the entire web to all countries and all languages, and so we'd like to hear about how we can ensure that a requirement for an icon could meet this need.<br />
<br />
==== Insert new term in Glossary ====<br />
We extensively examined several proposals for "plain language" requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for a Success Criteria. Also, there was some concern about requirements for freedom of expression.<br />
<br />
There is a strong possibility that there are ideas that the Working Group has simply not considered yet. Fortunately, the Working Group is committed to updating the specification far more rapidly than has been done in the past (targeting every 2 years), so these ideas and others will be able to be considered more fully in the near future.<br />
<br />
=== 589 === <br />
https://github.com/w3c/wcag21/issues/589<br />
<br />
Proposed response (AWK):<br />
Thank you for your comment. We understand your concern about PDF/UA including requirements that are unrelated to reflow in a PDF document. The possible technique has not been drafted or approved, so we appreciate your feedback. It is important to point out that techniques are not required, but they are sufficient, so if a PDF/UA conforming document would always meet the reflow requirements, we could make a technique that clarified this connection, but we would undoubtedly include other techniques as well that would allow a PDF to meet the reflow SC without conforming to PDF/UA.<br />
<br />
Of course, as you indicate, to include a PDF/UA-related technique we would need to consider the testing questions you mention and more.<br />
<br />
We have work to do to ensure that the understanding and techniques documents are up to date and accurate, but it is worth mentioning that the plan moving forward is that the non-normative techniques and understanding documents will be able to be updated continuously in the event that new information or errors are identified.<br />
<br />
=== 605 === <br />
https://github.com/w3c/wcag21/issues/605 Assigned to JOC:<br />
<br />
Proposed response (by Mike Gower):<br />
<br />
The initial goal of this SC was broader in scope but various considerations were identified which led the authors to keep the scope contained. Instead the intention is to list Best Practices and Advisory Techniques which could address broader Changes of Content. To that end, the SC language will not be changed.<br />
<br />
Here are specific responses to some of the points raised in the issue:<br />
<br />
> addresses the implementation of status messages, but doesn't say there needs to be a status message (essentially you can pass by not having a status message)<br />
<br />
That is by design. WCAG has a history of defining content requirements when the content is ''present''.<br />
<br />
Any attempt to make status messages a requirement will inevitably lead to poor implementations that make applications unusable by screen reader users -- the exact opposite of the goal. It was felt that significant scrutiny is given by designers to information they add to the UI. Restricting the SC to cover such information, where it does not alter a user's context (no change of context), seemed like a way to ensure messages were appropriate and limited.<br />
<br />
> indicates that the info be presented by AT without receiving focus<br />
<br />
That is not exactly what the SC is saying. It defines status messages as items that do not take focus (change of content without being a change of context), and _then_ makes requirements where such items exist. The SC does not restrict messages from being displayed in a dialog, for example. Such a message is a change of context and so does not meet the definition of a status message, and so is not covered by it (being instead covered by 4.1.2).<br />
<br />
> The need (and reasonable implementation) is not limited to markup languages... An interactive book implemented in Swift or Objective-C for iOS can certainly easily provide notification through AT, for example.<br />
<br />
The working group spent considerable time debating removing the markup language restriction. In the end, the group felt there is not enough research, evidence or best practices to apply this to other technologies. WCAG 2.0 and 2.1 apply to content at a URL. However, we'd be glad to have you propose a technique for how to apply this to other technologies that we could add as a best practice for those who may be trying to apply WCAG to content not at a URL.<br />
<br />
> If a change of content causes new content or functionality to appear on the screen, at least one of the following is true:<br />
<br />
We believe this effectively means "For each change of content at least one of the following is true:" We had several iterations with a similar approach to this, covering similar scenarios. All were abandoned due to nuances of implementation or testing. Some of those have been identified below.<br />
<br />
> The new content appears directly after the control that triggers it in the reading order.<br />
<br />
If the new content is a user interface control, this will likely be detected by screen readers. (Although issues with latency can cause focus issues; for example, where the user's act of leaving a control triggers a change, the user's focus may move to the next existing item before coding updates the DOM, thus the user bypasses the new control.)<br />
<br />
But what if the new content is an element that does not take focus? If the screen reader user has previously perused the page and is now navigating by pressing Tab, how is the screen reader user to know the new information exists? Since an author could use this bullet to bypass notifying users (the first bullet), it seems to lose a key accomplishment of the current SC language.<br />
<br />
> For content that is updated on a regular basis, or is updated so frequently that status messages may be disruptive, the user is advised of the type and frequency of updates (e.g. through a section heading or label)<br />
<br />
These "regular basis" and "disruptive" parameters would have to be defined in a way that was testable. The manner of advising the user would itself be quite difficult to establish in language that ensured it was testable. There is danger that this would be poorly implemented and would degrade the experience for a screen reader user. Perhaps in future iterations of WCAG we can find standardized and testable ways of notifying users of content that updates frequently without this risk of interfering with their experience.<br />
<br />
Some examples of interactions which may not be covered/considered by your alternative proposal:<br />
<br />
- chat clients and other dynamic interactive content where the content changes are related to the primary page but not ultimately initiated by the user<br />
<br />
- twitter feeds and other updating content whose frequency of change and nature of content changes can vary markedly based on parameters beyond the author's control or ability to predict accurately.<br />
<br />
- existing content that is altered rather than content that is added (e.g., the items in a select is updated based on a user's chosen value in a control, such as the choice of a country updating the values in the "State/province" select)<br />
<br />
=== 620 ===<br />
https://github.com/w3c/wcag21/issues/620 Related question asked by JOC, awaiting response and will then draft response: Assigned to JOC<br />
<br />
Proposed WG response (Detlev)<br />
<br />
Thank you for your comment. You propose to remove 'user motion' to exclude situations where the user is moving and the device just observing. The aim of the user motion part of the SC was to address motions like hand gestures that are observed by the camera or other sensors that can trigger certain events (such as forwarding a presentation, or panning a view). We have changed the SC text and the understanding text to clarify that 'user motion' means explicit actuation in the context of this SC. We have spelled out that scenarios where the user moves without explixitly actuating content (as in your your Leap Motion example) or where the device just observes without the user intentionally gesturing towards the device, are not in scope of this SC.<br />
<br />
We will mark this issue as "defer" to ensure that it is reviewed at an appropriate time in the future.<br />
<br />
=== 621 ===<br />
https://github.com/w3c/wcag21/issues/621<br />
<br />
Proposed response (Detlev)<br />
<br />
Thank you for your comment. You raise two issues - one is splitting device motion and user motion into separate SCs, the second is making us aware of a third type of similar functionality, that of motion / events in the field of view of the device (device is observing). We agree that this is a separate issue and potentially, a separate SC. In this SC, the issue is active, purposeful user input.<br />
We believe that the SC Motion Actuation addresses broadly issues common to two scenarios: firstly when the user moves the device itself (shaking, titling, panning) and secondly, when the user motions towards the device, i.e. carries out gestures aimed at actuating functions. We think that both scenarios can therefore be treated in one SC. <br />
<br />
We have updated the SC text and the Understanding text to clarify that input caused by the user moving through space, and situations where the device is observing anything other than purposeful user inputs, are not covered by this SC. <br />
<br />
As to your suggestion to separate out device and user motion, we will mark this issue as "defer" to ensure that it is reviewed at an appropriate time in the future.<br />
<br />
=== 622 ===<br />
https://github.com/w3c/wcag21/issues/622 Assigned to Detlev<br />
<br />
Proposed response (Detlev)<br />
<br />
Thank you for your comment. You describe usage scenarios where input happens not via a particular user motion, but via the position or orientation of the device. This issue is likely to become more important with the spread or AR / VR use scenarios. However, we believe it can be separated from the use case of motion actuation where motion is relative to the device and the exact position (e.g. on the z-axis, distance to ground) seems less relevant. The case of orientation (no position lock unless by user choice, content adapts to user-chosen orientation) seems already addressed by the SC 2.6.2 Orientation.<br />
<br />
You raise an interesting issue when you talk of alternatives other than user interface controls that still use motion but adapt in other ways (e.g., by lowering AR / VR objects for wheelchair users), motivated by the aim to not negate the full experience for wheelchair users (and many others). While different accommodations are certainly useful and should be encouraged, they would not negate the need for a means of input that works with keyboard and pointer interfaces. (An analogy might be sign language: Having a sign language version of a video talk is great, but it does not negate the requirement for captions.) You make the point that in the future, the availability of those other accommodations might be the difference between participation and exclusion (through exceptions) from entire categories of software. Requirements for alternative accommodations would be a good subject for a future SC as these technologies become more mature and widespread. We are open to suggestions to include additional techniques as optional best practices in the understanding document. Can you provide a description and examples that could be used?<br />
<br />
=== 624 ===<br />
https://github.com/w3c/wcag21/issues/624<br />
<br />
Thank you for your comment. It is hard to make changes to the list at this point, However, these are not the terms that need to be used, just the concepts that need to be addressed. In other words, the vocabulary you are using can use a term "new" and conform. <br />
<br />
You are also invited to comment on the personalization task force and open an issue to suggest any term changes there, which we know would be very welcome. (see https://github.com/w3c/personalization-semantics/issues)<br />
<br />
=== 628 ===<br />
https://github.com/w3c/wcag21/issues/628<br />
<br />
=== 629 ===<br />
https://github.com/w3c/wcag21/issues/629<br />
<br />
Thank you for your feedback. You are correct - will also be able to use an aria vocabulary that is being produced. (https://w3c.github.io/personalization-semantics/content/index.html)<br />
The current version of the understanding document identifies different ways to meet the success criteria and the new draft of the understanding document gives alternative ways to meet each item in the list.<br />
<br />
To make sure the success criteria are sufficiently mature we will be adding techniques and ensure that there are implementations and user-agent support before we leave CR as per our exit criteria - see https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria<br />
<br />
=== 631 ===<br />
https://github.com/w3c/wcag21/issues/631 . (Answer by David MacDonald)<br />
<br />
Thank you for your question. This Success Criteria was developed in the Mobile Task Force with the primary purpose to ensure that pointer targets are large enough for people with dexterity disabilities to hit the touch target in mobile, with the additional benefit of providing larger click targets for mouse users on desktop who have dexterity disabilities. This was not covered in WCAG 2.0. The task force looked at a number of studies and other standards, such as the BBC Mobile Guidelines. One study demonstrated that some people with dexterity disabilities needed a target size of 100px by 100px. So we knew that we could only provide a minimum value and encourage the author to make targets as large as possible. The idea of the minimum size requirement in the success criteria was to choose a value as large as possible without negatively impacting design. Google mobile developer guidelines recommended 48px by 48px. <br />
<br />
We took Apple's recommendation and amended one dimension in response to comments that 44px by 44px was too large for many interfaces, especially vertical lists of text links, and we added a list of exceptions. We have removed the 22px requirement for one dimension in response to your comment. We expect that the other dimension not required in the Success Criteria will be at least the default row height in right to left languages. Apple's mobile recommendation was 44px by 44px. We feel 44px in one direction strikes the right balance. The intent is that users with mild to moderate dexterity disabilities can hit this minimum target without zooming, while users who need a very large target would likely have to zoom in.<br />
<br />
=== 634 ===<br />
https://github.com/w3c/wcag21/issues/634<br />
<br />
Thanks for the comment. We agree that the definition needs to be clarified. We are changing the definition to:<br />
<br />
Option A (detlev):<br />
<br />
A single pointer describes a means of pointer input that operates on one particular screen location. The input can be indirect (a mouse, joystick or trackpad cursor) or direct (a stylus or finger on a touch screen). The operation through single pointer includes single taps and clicks, double taps and clicks as well as and long presses. It excludes path-based and multi-point gestures.<br />
<br />
Option B (AWK): <br />
<br />
Pointer input that operates on one screen location, including single taps and clicks, double-taps and clicks, and long presses.<br />
<br />
The input can be indirect (a mouse, joystick or trackpad cursor) or direct (a stylus or finger on a touch screen). It excludes path-based and multi-point gestures.<br />
<br />
=== 635 ===<br />
https://github.com/w3c/wcag21/issues/635 (answer from Lisa)<br />
<br />
Thanks for the feedback. We have written an understanding document and will be drafting techniques that explain this.<br />
The current version of the understanding document identifies different ways to meet the success criteria and the new draft of the understanding document gives alternative ways to meet each item in the list.<br />
<br />
It is worth noting that success criteria specify what needs to be done but are never technology specific. How to reach them or what terms to use is always left to techniques. There are often more than one way to achieve success (such as using native html, xforms or ARIA)<br />
<br />
=== 636 ===<br />
https://github.com/w3c/wcag21/issues/636 (answer by Lisa) <br />
<br />
The new wording just requires that the purpose is programmatically determined. We will be adding techniques and have user agent support before we leave CR as per are exit criteria - see https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria.<br />
<br />
It is worth noting that success criteria specify what needs to be done but are never technology specific. How to reach them or what terms to use is always left to techniques. There are often more than one way to achieve success (such as using native html, xforms or ARIA)<br />
<br />
=== 637 ===<br />
https://github.com/w3c/wcag21/issues/637<br />
<br />
=== 644 ===<br />
https://github.com/w3c/wcag21/issues/644 (Assigned to Laura):<br />
<br />
Proposed response:<br />
<br />
Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:<br />
<br />
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."<br />
<br />
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.<br />
<br />
We will also clarify the applicability of this SC in the Understanding document.<br />
<br />
=== 649 ===<br />
https://github.com/w3c/wcag21/issues/649<br />
<br />
=== 650 ===<br />
https://github.com/w3c/wcag21/issues/650 . (Answer:David MacDonald)<br />
<br />
It asks if tabbed interfaces are covered in hover or focus SC.<br />
Analysis: There is a discussion [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JanMar/subject.html here] Scroll down to Issue 650. <br />
Alastair asked if we can we pick up on the ‘additional’ part of: “…keyboard focus triggers additional content to become visible” A tab set switches content, it doesn’t show additional content.<br />
David said: Can put that in understanding content but might need normative language to distinguish additional from switching. Opens another question. If users don't move their mouse to dismiss popup, how are they expected to dismiss it.... with the keyboard? If so, why not just say that? <br />
<br />
Need to resolve before proceeding with a response.<br />
<br />
=== 651 ===<br />
https://github.com/w3c/wcag21/issues/651<br />
<br />
=== 653 ===<br />
https://github.com/w3c/wcag21/issues/653<br />
<br />
=== 654 ===<br />
https://github.com/w3c/wcag21/issues/654<br />
<br />
=== 655 ===<br />
https://github.com/w3c/wcag21/issues/655<br />
<br />
Proposed response (AWK):<br />
Thank you for your comment. The language suggested doesn't fully account for the intent of the exception as currently written since the exception is covering both that the ... (needs more work)<br />
<br />
=== 656 ===<br />
https://github.com/w3c/wcag21/issues/656<br />
<br />
Proposed response (AC):<br />
Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:<br />
<br />
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."<br />
<br />
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.<br />
<br />
=== 657 and 677 ===<br />
https://github.com/w3c/wcag21/issues/657<br />
<br />
https://github.com/w3c/wcag21/issues/677<br />
<br />
Proposed response (Laura):<br />
<br />
Thank you for your comment. Because we have no research on CJK languages, the Working Group will be adding an exemption for them at the end of the SC that reads:<br />
<br />
"Exception: Text in Chinese, Japanese, and Korean languages."<br />
<br />
Proposed response (AWK):<br />
Thank you for your comment. These properties are defined in CSS and in typographical principals, and they adhere to the meaning used in CSS. We will modify the description for paragraph spacing to "spacing following paragraphs" instead of "spacing underneath paragraphs" to address the implicit western language bias in this item.<br />
<br />
=== 659 ===<br />
https://github.com/w3c/wcag21/issues/659<br />
<br />
=== 660 ===<br />
https://github.com/w3c/wcag21/issues/660<br />
<br />
=== 661 ===<br />
https://github.com/w3c/wcag21/issues/661<br />
<br />
=== 663 ===<br />
https://github.com/w3c/wcag21/issues/663 (Answer by Detlev)<br />
<br />
Thank you for your suggestion. We agree that your addition clarifies the text of SC 2.5.1 Pointer gestures. Path-based gestures are often carried out with a single pointer (as in drag-and-drop) so including an explicit reference ("...can be operated with a single pointer ''without a path-based gesture''") leaves less room for misunderstanding.<br />
<br />
=== 665 ===<br />
https://github.com/w3c/wcag21/issues/665<br />
<br />
=== 666 ===<br />
https://github.com/w3c/wcag21/issues/666<br />
<br />
=== 667 ===<br />
https://github.com/w3c/wcag21/issues/667<br />
<br />
Proposal emailed to list 1/11/2018<br />
<br />
=== 668 ===<br />
https://github.com/w3c/wcag21/issues/668<br />
<br />
Makoto to review latest ed draft.<br />
<br />
=== 669 ===<br />
https://github.com/w3c/wcag21/issues/669<br />
<br />
=== 670 ===<br />
https://github.com/w3c/wcag21/issues/670<br />
<br />
=== 671 ===<br />
https://github.com/w3c/wcag21/issues/671<br />
<br />
Proposed response: (from AWK)<br />
Thank you for the comment. We agree that your wording is easier to read and will make the change to the structure, although there are other changes that are being implemented (e.g. changing "touch" to "pointer") so the wording will not be exact.<br />
<br />
(Alternative answer by Detlev - sorry Andrew, I worked in the wrong section (completed issues) and did not see you had drafted this respose already)<br />
<br />
Thank you for your suggestion. We agree that the definition of target was hard to parse and needed updating. We have changed "touch action" to "pointer action" to cover all pointer input, not just touch. We have also simplified the text explaining that parts of a target covered by another target must be excluded in target size measurements. <br />
<br />
Pull request for revised definition of 'target': https://github.com/w3c/wcag21/pull/673<br />
<br />
=== 672 ===<br />
https://github.com/w3c/wcag21/issues/672<br />
<br />
=== 674 ===<br />
https://github.com/w3c/wcag21/issues/674<br />
<br />
=== 676 ===<br />
https://github.com/w3c/wcag21/issues/676<br />
<br />
Thank you for the comment. We are updating the SC and modifying the first exception so that it starts with the description "Supported Interfaces", but the phrase "accessibility supported" is still used in the description, as follows:<br />
<br />
"The motion is used to operate functionality through an <a>accessibility supported</a> interface;"<br />
<br />
The Understanding document will be updated to reflect clearly that the intent is that where motion is used to operate an interface that has accessibility support (meaning that it has user agent and assistive technology support) that motion is exempt. For example, a user might use a head mouse system that operates using the camera in order to interface with the pointer/mouse interface would be exempted. We hope this addresses your concern.<br />
<br />
=== 677 ===<br />
https://github.com/w3c/wcag21/issues/677<br />
<br />
=== 680 ===<br />
https://github.com/w3c/wcag21/issues/680<br />
<br />
<br />
== Issues that have been addressed ==<br />
<br />
=== 150 ===<br />
https://github.com/w3c/wcag21/issues/150 Assigned to Goodwitch:<br />
<br />
Proposed Response (by Goodwitch): Thanks for your comment, Scott. We think we have addressed your concerns in the latest version of this SC and the updated Understanding Document. <br />
<br />
SC Changes - In the first draft of WCAG 2.1 (20170228) the proposed SC text for Graphics Contrast had used "essential" in both the positive and in the negative (as part of an exception). Based on your feedback (and feedback from others) we refined this SC text to only use "essential" as part of the exception. This language is parallel to the way "essential" is used in WCAG 2.0 SC 1.4.5 Images of Text. <br />
<br />
Understanding Changes - Examples to clarify this SC have been created in the draft understanding document that is published here https://rawgit.com/w3c/wcag21/graphics-contrast/understanding/21/graphics-contrast.html More examples and sufficient techniques will continue to be added to further enhance understandability and consistency in testing.<br />
<br />
=== 601 ===<br />
https://github.com/w3c/wcag21/issues/601 Assigned to JOC:<br />
<br />
Proposed Response (by JOC): <br />
Thank you for your observation. We believe that you refer to section 7.1 Common Control Purposes" https://www.w3.org/TR/WCAG21/#control-purposes. The Working Group will add a item to represent "skip to" links.<br />
<br />
<br />
=== 602 ===<br />
https://github.com/w3c/wcag21/issues/602<br />
<br />
Proposed Response (by AWK): <br />
The list of purposes is explicitly not requiring that the author use the specific text to identify a purpose, so adding the requirement to use the listed name is different than what we intended. For example, the "Table of Contents" purpose may be referenced using a different term depending on whether the author is incorporating metadata from one schema or another - one schema might use "toc" and another might use "tableOfContents" but as long as they are aligned with the purpose expressed in the list (and as long as there is accessibility support) either would be sufficient.<br />
<br />
=== 608 ===<br />
https://github.com/w3c/wcag21/issues/608<br />
<br />
Proposed response (from AWK): <br />
<br />
We are closing this issue as it is redundant to issue #609.<br />
<br />
=== 609 ===<br />
https://github.com/w3c/wcag21/issues/609<br />
<br />
Proposed response (from AWK): <br />
<br />
We are happy to make the changes from "which" to "that" for the WCAG 2.1 SC, glossary definitions, and within the "common purposes" section in order to make the guidelines more clear. We cannot change all of the suggested items, including boilerplate text and text within WCAG 2.0 glossary items. The main change needed to make it clear that sentence parts now starting with "which" are restrictive clauses is dropping the comma. The comma will be removed in cases where we need restrictive clauses.<br />
<br />
=== 613 ===<br />
https://github.com/w3c/wcag21/issues/613<br />
<br />
Editorial. Closed by AWK<br />
<br />
=== 614 ===<br />
https://github.com/w3c/wcag21/issues/614<br />
<br />
Editorial. Fixed and closed by AWK<br />
<br />
=== 615 ===<br />
https://github.com/w3c/wcag21/issues/615<br />
<br />
Editorial. Fixed and closed by AWK<br />
<br />
=== 616 ===<br />
https://github.com/w3c/wcag21/issues/616<br />
<br />
Proposed response (from AWK):<br />
<br />
The Working Group made the decision to not modify existing SC from WCAG 2.0, which is why these requirements are in a new SC. If you have any suggestions for an SC title that would address your concerns, please suggest it.<br />
<br />
=== 617 ===<br />
https://github.com/w3c/wcag21/issues/617<br />
<br />
Proposed response (from AWK):<br />
<br />
We agree that there is a potential for confusion, and have made a change to the SC text to read:<br />
<br />
"User Interface Components: Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;"<br />
<br />
=== 618 ===<br />
https://github.com/w3c/wcag21/issues/618<br />
<br />
Proposed response (by AWK): <br />
<br />
The first two items in your comment are editorial and have been changed as suggested. Regarding the comment about the use of "social Security" we will change the SC text to use your suggestion of "National identification number" as follows:<br />
<br />
"Authentication process involves basic personal identification information to which the user has easy access, such as name, address, email address, and National identification number."<br />
<br />
=== 619 ===<br />
https://github.com/w3c/wcag21/issues/619 Assigned to JOC and Detlev<br />
<br />
Proposed WG response (Detlev)<br />
<br />
Thank you for your suggestion. We agree that for interactions that include activation by positioning the device in a particular geographic location (your virtual fountain example), the requirement to provide alternative means of input does not apply. However, pointing a phone in the direction of a virtual location would still be a problem for a user with a motor impairment or a mounted device, so this would not negate the need for keyboard/pointer-accessible alternative modes of input. We believe the provision of alternative accommodations like the one you suggest could be included in a future SC focused on the use scenario of AR / Vr applications, and we are marking this issue as "defer" to ensure that it is reviewed at an appropriate time.<br />
<br />
=== 630 ===<br />
https://github.com/w3c/wcag21/issues/630 (Answer by Mike Gower)<br />
<br />
> I find this really confusing and would like some examples to illustrate these criteria.<br />
<br />
The Understanding document is in the process of being updated, and will offer examples and clarity. The current draft provides some explanation and [Examples](https://w3c.github.io/wcag21/understanding/21/content-on-hover-or-focus.html)<br />
<br />
> If there must be a mechanism to dismiss content without moving the pointer or keyboard focus, what might that look like? <br />
<br />
The normal mechanism for dismissing any kind of overlay is the Escape key; if that is implemented, this first bulleted requirement is met. Note that the wording of the SC does not prevent an author from adding in a mouse-equivalent affordance for this (such as simply moving away from the trigger/new content or hitting a close button displayed as a ‘x’ in the upper right corner of the overlay). The SC simply requires that there be a method that does not involve moving the mouse.<br />
<br />
> Most mechanisms to dismiss content ask that the user click on a button, which requires moving the pointer or keyboard focus.<br />
<br />
> What is the benefit to being able to hover over additional content that only appears on hover?<br />
<br />
The specific reason for a requirement to dismiss the on-hover overlay without moving the mouse, involves low vision users or users with reduced fine motor skills. Low vision users with a substantial level of magnification have a limited viewport. If they accidentally trigger new content with hover, they need to be able to dismiss that new content without losing their current point of regard. Otherwise, they are put in the situation where they must move their entire viewport away from the location they wished to interact with in order to dismiss the new unwanted content. After re-orienting themselves back again after the new content disappears, they then may accidentally trigger the hover again, repeating the same experience. Similarly, a user who cannot easily control the mouse and so is more prone to accidental triggering of on-hover content, needs a method of easily dismissing that is not mouse based.<br />
<br />
As will be made clear in the Understanding document, this SC is not recommending or encouraging the use of On Hover or On Focus as the trigger for displaying new content. This is considered a poor interaction by many, since users may easily inadvertently trigger new content. However, where an author elects to employ On Hover as a trigger, this SC places requirements on the implementation which make the resulting experience more accessible.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Draft_Responses_to_Dec_WD_Issues&diff=9076Draft Responses to Dec WD Issues2018-01-10T18:15:41Z<p>Dmacdona: /* 631 */</p>
<hr />
<div>== This page contains draft responses to issues logged in GitHub ==<br />
Open issues: https://github.com/w3c/wcag21/labels/Dec%20WD%20Comment<br />
<br />
If your issue is not listed, please add it as a heading 3 and make sure to indicate who drafted the response. See below for examples to follow in terms of organization of the information.<br />
<br />
Please write the responses in a way that can be easily copied/pasted into the issue. For each issue the editors will add "Official WG response: Thank you for your comment." to the start, so it isn't necessary to include that in the response.<br />
<br />
When an item is approved by the WG it will be indicated in the heading.<br />
<br />
=== 261 ===<br />
https://github.com/w3c/wcag21/issues/261 <br />
<br />
Proposed response (from AWK):<br />
Thank you for your comment. Since your comment was logged we have changed the SC and definition of target and we believe that your concerns are addressed. First, we are changing the first sentence of the definition to:<br />
<br />
Region of the display that will accept a pointer action, such as the interactive area of a user interface component.<br />
<br />
Second, regarding the concern about inline content such as footnotes, we now have an exception for links in a sentence or block of text.<br />
<br />
We hope that these address your concerns.<br />
<br />
<br />
=== 408 ===<br />
https://github.com/w3c/wcag21/issues/408<br />
<br />
Proposed Response (by AWK): Thank you for the comment. The use of "essential" in WCAG 2.1 is needed in some of the new SC as a way to convey an exception for content that must be presented in a specific manner and it is useful to make consistent use of the defined term for this purpose. In the SC identified the term essential refers to the specific way a graphic is presented, rather than the graphic itself being essential. We will clarify this in the understanding document.<br />
<br />
"Essential" is a defined term in WCAG, meaning "if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform".<br />
<br />
=== 520 ===<br />
https://github.com/w3c/wcag21/issues/520<br />
<br />
Proposed Response (by AWK): Thank you for the comment.<br />
<br />
You make four main points:<br />
# The WCAG development process excludes people with intellectual or learning disabilities<br />
# Request for three new Success Criteria and a glossary item<br />
#* Navigation to plain language summary<br />
#* Plain language summary<br />
#* Plain language summary of main pages<br />
# Request for modification of SC 3.1.2<br />
# WCAG 2.1 doesn’t include measures for people with intellectual and learning disabilities<br />
<br />
It has been very important to the Working Group that people with various types of cognitive disabilities are included in the work of the group. We formed a task force for cognitive accessibility and welcomed many new members into the working group, many of whom either have some type of cognitive disability or work regularly on the topic. There is no question that the process of developing a specification with a group of almost 100 people providing input can be taxing due to the volume of email, wiki page updates, and spec updates that take place, but the W3C and the Working Group are committed to supporting the needs of any group members to help ensure that it is possible for anyone to participate to the greatest extent possible. Still, we recognize that there is always room for improvement and are open to any suggestions you may have. Although our COGA task force did a significant amount of [https://www.w3.org/TR/coga-user-research/ background research], and an extensive [https://www.w3.org/TR/2017/WD-coga-gap-analysis-20171207/ Gap Analysis], it appears that a Success Criteria for a Plain Language Summary as found in your comment was not proposed by any stakeholders in the timeframe for WCAG 2.1. However, there is a proposed Success Criteria called [https://www.w3.org/TR/WCAG21/#identify-common-purpose Identify Common Purpose] which may allow personalization and simplification of interfaces.<br />
<br />
Regarding the inclusion of requirements for people with intellectual and learning disabilities, while we agree that the set of Success Criteria does not address every possible improvement that end users might benefit from, there are substantial challenges to ensure they meet the following acceptance criteria for Success Criteria both in WCAG 2.0 and 2.1:<br />
<br />
* Be testable through automated or manual processes.<br />
* Apply to all content (including many human languages - internationalization) unless preconditions for the application of the success criteria are explicitly identified.<br />
* Apply across technologies to the greatest extent possible. (Technology-specific issues should usually be addressed in Techniques.)<br />
* Have Success Techniques which demonstrate that each Success Criterion is implementable, using readily-available formats, user agents, and assistive technologies.<br />
See: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria. <br />
<br />
These are some of the core requirements for Success Criteria that are very important but do set a challenging bar for new criteria to meet. If Success Criteria are included that do not meet these requirements there is a strong risk that WCAG 2.1 might not gain consensus or might not be adopted. Of the currently 18 new Success Criteria, approximately half are viewed as providing some benefit for users with cognitive disabilities. <br />
<br />
We should also mention that WCAG 2.0 [http://www.davidmacd.com/blog/wcag-for-low-vision-cognitive-disabilites.html provides important help for people with cognitive and learning disabilities]. We hope that there will be significant advances in Assistive Technology for people with cognitive and learning disabilities in the future, which may facilitate further WCAG requirements upon authors and leverage more of the the existing requirements.<br />
<br />
==== Suggested new Success Criteria "Navigation to plain language summary" ====<br />
<br />
The deadline for introducing new Success Criteria closed over the summer as a result of the tight Working Group Charter timeline. However, we will mark this issue with a label (“defer”) to ensure that we can review these at the right time when we are able to review new proposals. This also impacts the suggestion for a definition since that definition is related to the proposed new criteria.<br />
<br />
We can provide it to the Cognitive Task Force (COGA) for consideration in a future version. It would impact the most important part of most web template designs and we expect there would be significant response from industry, so any objective research and studies your team can provide may help the COGA team with justifying this UI requirement universally across all web sites may be helpful.<br />
<br />
==== The suggested Amendment Success Criterion 3.1.2 Language of Parts ====<br />
<br />
Amending existing WCAG 2.0 Success Criteria is not permitted for WCAG 2.1 development, so in addition to the timeline consideration above, this suggestion would not be possible during this round of development.<br />
<br />
We can provide it to the Cognitive Task Force (COGA) for future consideration. In addition to the concerns about impact on site design, there is currently no assistive technology we know of that could make use of programmatically determined summaries in plain language. We suggest that this be demonstrated to the COGA team.<br />
<br />
==== Insert new Criterion 3.1.7: Plain Language Summary of site ====<br />
<br />
We extensively examined several proposals for plain language requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for an Success Criteria that could apply to "all content", and also there was some concern about requirements for freedom of expression. Regarding applying a plain language to a summary, these concerns may or may not be able to be overcome. <br />
<br />
We can provide it to the Cognitive Task Force (COGA) for future consideration.<br />
<br />
==== Ensure the summary page is clearly identified by a non-verbal icon. ====<br />
<br />
In addition to the timeline considerations above, we have had trouble gaining consensus on specific icons in the past. There are different cultures and different environments which may or may not approve of a particular icon design. We know of no such internationally recognized icon. WCAG strives to apply across the entire web to all countries and all languages, and so we'd like to hear about how we can ensure that a requirement for an icon could meet this need.<br />
<br />
==== Insert new term in Glossary ====<br />
We extensively examined several proposals for "plain language" requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for a Success Criteria. Also, there was some concern about requirements for freedom of expression.<br />
<br />
There is a strong possibility that there are ideas that the Working Group has simply not considered yet. Fortunately, the Working Group is committed to updating the specification far more rapidly than has been done in the past (targeting every 2 years), so these ideas and others will be able to be considered more fully in the near future.<br />
<br />
=== 589 === <br />
https://github.com/w3c/wcag21/issues/589<br />
<br />
Proposed response (AWK):<br />
Thank you for your comment. We understand your concern about PDF/UA including requirements that are unrelated to reflow in a PDF document. The possible technique has not been drafted or approved, so we appreciate your feedback. It is important to point out that techniques are not required, but they are sufficient, so if a PDF/UA conforming document would always meet the reflow requirements, we could make a technique that clarified this connection, but we would undoubtedly include other techniques as well that would allow a PDF to meet the reflow SC without conforming to PDF/UA.<br />
<br />
Of course, as you indicate, to include a PDF/UA-related technique we would need to consider the testing questions you mention and more.<br />
<br />
We have work to do to ensure that the understanding and techniques documents are up to date and accurate, but it is worth mentioning that the plan moving forward is that the non-normative techniques and understanding documents will be able to be updated continuously in the event that new information or errors are identified.<br />
<br />
=== 605 === <br />
https://github.com/w3c/wcag21/issues/605 Assigned to JOC:<br />
<br />
Proposed response (by Mike Gower):<br />
<br />
The initial goal of this SC was broader in scope but various considerations were identified which led the authors to keep the scope contained. Instead the intention is to list Best Practices and Advisory Techniques which could address broader Changes of Content. To that end, the SC language will not be changed.<br />
<br />
Here are specific responses to some of the points raised in the issue:<br />
<br />
> addresses the implementation of status messages, but doesn't say there needs to be a status message (essentially you can pass by not having a status message)<br />
<br />
That is by design. WCAG has a history of defining content requirements when the content is ''present''.<br />
<br />
Any attempt to make status messages a requirement will inevitably lead to poor implementations that make applications unusable by screen reader users -- the exact opposite of the goal. It was felt that significant scrutiny is given by designers to information they add to the UI. Restricting the SC to cover such information, where it does not alter a user's context (no change of context), seemed like a way to ensure messages were appropriate and limited.<br />
<br />
> indicates that the info be presented by AT without receiving focus<br />
<br />
That is not exactly what the SC is saying. It defines status messages as items that do not take focus (change of content without being a change of context), and _then_ makes requirements where such items exist. The SC does not restrict messages from being displayed in a dialog, for example. Such a message is a change of context and so does not meet the definition of a status message, and so is not covered by it (being instead covered by 4.1.2).<br />
<br />
> The need (and reasonable implementation) is not limited to markup languages... An interactive book implemented in Swift or Objective-C for iOS can certainly easily provide notification through AT, for example.<br />
<br />
The working group spent considerable time debating removing the markup language restriction. In the end, the group felt there is not enough research, evidence or best practices to apply this to other technologies. WCAG 2.0 and 2.1 apply to content at a URL. However, we'd be glad to have you propose a technique for how to apply this to other technologies that we could add as a best practice for those who may be trying to apply WCAG to content not at a URL.<br />
<br />
> If a change of content causes new content or functionality to appear on the screen, at least one of the following is true:<br />
<br />
We believe this effectively means "For each change of content at least one of the following is true:" We had several iterations with a similar approach to this, covering similar scenarios. All were abandoned due to nuances of implementation or testing. Some of those have been identified below.<br />
<br />
> The new content appears directly after the control that triggers it in the reading order.<br />
<br />
If the new content is a user interface control, this will likely be detected by screen readers. (Although issues with latency can cause focus issues; for example, where the user's act of leaving a control triggers a change, the user's focus may move to the next existing item before coding updates the DOM, thus the user bypasses the new control.)<br />
<br />
But what if the new content is an element that does not take focus? If the screen reader user has previously perused the page and is now navigating by pressing Tab, how is the screen reader user to know the new information exists? Since an author could use this bullet to bypass notifying users (the first bullet), it seems to lose a key accomplishment of the current SC language.<br />
<br />
> For content that is updated on a regular basis, or is updated so frequently that status messages may be disruptive, the user is advised of the type and frequency of updates (e.g. through a section heading or label)<br />
<br />
These "regular basis" and "disruptive" parameters would have to be defined in a way that was testable. The manner of advising the user would itself be quite difficult to establish in language that ensured it was testable. There is danger that this would be poorly implemented and would degrade the experience for a screen reader user. Perhaps in future iterations of WCAG we can find standardized and testable ways of notifying users of content that updates frequently without this risk of interfering with their experience.<br />
<br />
Some examples of interactions which may not be covered/considered by your alternative proposal:<br />
<br />
- chat clients and other dynamic interactive content where the content changes are related to the primary page but not ultimately initiated by the user<br />
<br />
- twitter feeds and other updating content whose frequency of change and nature of content changes can vary markedly based on parameters beyond the author's control or ability to predict accurately.<br />
<br />
- existing content that is altered rather than content that is added (e.g., the items in a select is updated based on a user's chosen value in a control, such as the choice of a country updating the values in the "State/province" select)<br />
<br />
=== 620 ===<br />
https://github.com/w3c/wcag21/issues/620 Related question asked by JOC, awaiting response and will then draft response: Assigned to JOC<br />
<br />
Proposed WG response (Detlev)<br />
<br />
Thank you for your comment. You propose to remove 'user motion' to exclude situations where the user is moving and the device just observing. The aim of the user motion part of the SC was to address motions like hand gestures that are observed by the camera or other sensors that can trigger certain events (such as forwarding a presentation, or panning a view). We will qualify 'user motion' to mean explicit actuation in the context of this SC, and add to the understanding document to describe that scenarios where the user moves without explixitly actuating content (as in you your Leap Motion example) are not in scope of this SC.<br />
<br />
=== 621 ===<br />
https://github.com/w3c/wcag21/issues/621<br />
Question asked by JOC, awaiting response and will then draft response: Assigned to JOC and Detlev<br />
<br />
Proposed response (Detlev)<br />
<br />
Thank you for your comment. You raise two issues - one is splitting device motion and user motion into separate SCs, the second is making us aware of a third type of similar functionality, that of motion / events in the field of view of the device (device is observing). We agree that this is a separate issue and potentially, a separate SC. In this SC, the issue is active, purposeful user input.<br />
Your argument for creating two distinct SCs is that the requirements and techniques for user motion and device motion might evolve in different ways. This might be correct, but currently they would both require some alternative way of input that can be actuated via the keyboard interface (including speech input, switch etc.) and a pointer interface. We believe that the SC Motion Actuation addresses broadly issues common to both user and device motion (difficulty of intentional motion in the way required for input via sensors, possibly because of a motor impairment, possibly because the device is mounted), and that they can therefore be treated in one SC.<br />
<br />
=== 622 ===<br />
https://github.com/w3c/wcag21/issues/622 Assigned to Detlev<br />
<br />
Proposed response (Detlev)<br />
<br />
Thank you for your comment. You describe usage scenarios where input happens not via a particular user motion, but via the position or orientation of the device. This issue is likely to become more important with the spread or AR / VR use scenarios. However, we believe it can be separated from the use case of motion actuation where motion is relative to the device and the exact position (e.g. on the z-axis, distance to ground) seems less relevant. The case of orientation (no position lock unless by user choice, content adapts to user-chosen orientation) seems already addressed by the SC 2.6.2 Orientation.<br />
<br />
You raise an interesting issue when you talk of alternatives other than user interface controls that still use motion but adapt in other ways (e.g., by lowering AR / VR objects for wheelchair users), motivated by the aim to not negate the full experience for wheelchair users (and many others). While different accommodations are certainly useful and should be encouraged, they would not negate the need for a means of input that works with keyboard and pointer interfaces. (An analogy might be sign language: Having a sign language version of a video talk is great, but it does not negate the requirement for captions.) You make the point that in the future, the availability of those other accommodations might be the difference between participation and exclusion (through exceptions) from entire categories of software. Requirements for alternative accommodations would be a good subject for a future SC as these technologies become more mature and widespread. We are open to suggestions to include additional techniques as optional best practices in the understanding document. Can you provide a description and examples that could be used?<br />
<br />
=== 624 ===<br />
https://github.com/w3c/wcag21/issues/624<br />
<br />
Thank you for your comment. It is hard to make changes to the list at this point, However, these are not the terms that need to be used, just the concepts that need to be addressed. In other words, the vocabulary you are using can use a term "new" and conform. <br />
<br />
You are also invited to comment on the personalization task force and open an issue to suggest any term changes there, which we know would be very welcome. (see https://github.com/w3c/personalization-semantics/issues)<br />
<br />
=== 628 ===<br />
https://github.com/w3c/wcag21/issues/628<br />
<br />
=== 629 ===<br />
https://github.com/w3c/wcag21/issues/629<br />
<br />
Thank you for your feedback. You are correct - will also be able to use an aria vocabulary that is being produced. (https://w3c.github.io/personalization-semantics/content/index.html)<br />
The current version of the understanding document identifies different ways to meet the success criteria and the new draft of the understanding document gives alternative ways to meet each item in the list.<br />
<br />
To make sure the success criteria are sufficiently mature we will be adding techniques and ensure that there are implementations and user-agent support before we leave CR as per our exit criteria - see https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria<br />
<br />
=== 631 ===<br />
https://github.com/w3c/wcag21/issues/631 . (Answer by David MacDonald)<br />
<br />
Thank you for your question. This Success Criteria was developed in the Mobile Task Force with the primary purpose to ensure that pointer targets are large enough for people with dexterity disabilities to hit the touch target in mobile, with the additional benefit of providing larger click targets for mouse users on desktop who have dexterity disabilities. This was not covered in WCAG 2.0. The task force looked at a number of studies and other standards, such as the BBC Mobile Guidelines. One study demonstrated that some people with dexterity disabilities needed a target size of 100px by 100px. So we knew that we could only provide a minimum value and encourage the author to make targets as large as possible. The idea of the minimum size requirement in the success criteria was to choose a value as large as possible without negatively impacting design. Google mobile developer guidelines recommended 48px by 48px. <br />
<br />
We took Apple's recommendation and amended one dimension in response to comments that 44px by 44px was too large for many interfaces, especially vertical lists of text links, and we added a list of exceptions. We have removed the 22px requirement for one dimension in response to your comment. We expect that the other dimension not required in the Success Criteria will be at least the default row height in right to left languages. Apple's mobile recommendation was 44px by 44px. We feel 44px in one direction strikes the right balance. The intent is that users with mild to moderate dexterity disabilities can hit this minimum target without zooming, while users who need a very large target would likely have to zoom in.<br />
<br />
=== 634 ===<br />
https://github.com/w3c/wcag21/issues/634<br />
<br />
=== 635 ===<br />
https://github.com/w3c/wcag21/issues/635 (answer from Lisa)<br />
<br />
Thanks for the feedback. We have written an understanding document and will be drafting techniques that explain this.<br />
The current version of the understanding document identifies different ways to meet the success criteria and the new draft of the understanding document gives alternative ways to meet each item in the list.<br />
<br />
It is worth noting that success criteria specify what needs to be done but are never technology specific. How to reach them or what terms to use is always left to techniques. There are often more than one way to achieve success (such as using native html, xforms or ARIA)<br />
<br />
=== 636 ===<br />
https://github.com/w3c/wcag21/issues/636 (answer by Lisa) <br />
<br />
The new wording just requires that the purpose is programmatically determined. We will be adding techniques and have user agent support before we leave CR as per are exit criteria - see https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria.<br />
<br />
It is worth noting that success criteria specify what needs to be done but are never technology specific. How to reach them or what terms to use is always left to techniques. There are often more than one way to achieve success (such as using native html, xforms or ARIA)<br />
<br />
=== 637 ===<br />
https://github.com/w3c/wcag21/issues/637<br />
<br />
=== 644 ===<br />
https://github.com/w3c/wcag21/issues/644 (Assigned to Laura):<br />
<br />
Proposed response:<br />
<br />
Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:<br />
<br />
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."<br />
<br />
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.<br />
<br />
We will also clarify the applicability of this SC in the Understanding document.<br />
<br />
=== 649 ===<br />
https://github.com/w3c/wcag21/issues/649<br />
<br />
=== 650 ===<br />
https://github.com/w3c/wcag21/issues/650 . (Answer:David MacDonald)<br />
<br />
It asks if tabbed interfaces are covered in hover or focus SC.<br />
Analysis: There is a discussion [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JanMar/subject.html here] Scroll down to Issue 650. <br />
Alastair asked if we can we pick up on the ‘additional’ part of: “…keyboard focus triggers additional content to become visible” A tab set switches content, it doesn’t show additional content.<br />
David said: Can put that in understanding content but might need normative language to distinguish additional from switching. Opens another question. If users don't move their mouse to dismiss popup, how are they expected to dismiss it.... with the keyboard? If so, why not just say that? <br />
<br />
Need to resolve before proceeding with a response.<br />
<br />
=== 651 ===<br />
https://github.com/w3c/wcag21/issues/651<br />
<br />
=== 653 ===<br />
https://github.com/w3c/wcag21/issues/653<br />
<br />
=== 654 ===<br />
https://github.com/w3c/wcag21/issues/654<br />
<br />
=== 655 ===<br />
https://github.com/w3c/wcag21/issues/655<br />
<br />
Proposed response (AWK):<br />
Thank you for your comment. The language suggested doesn't fully account for the intent of the exception as currently written since the exception is covering both that the ... (needs more work)<br />
<br />
=== 656 ===<br />
https://github.com/w3c/wcag21/issues/656<br />
<br />
Proposed response (AC):<br />
Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:<br />
<br />
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."<br />
<br />
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.<br />
<br />
=== 657 ===<br />
https://github.com/w3c/wcag21/issues/657<br />
<br />
=== 659 ===<br />
https://github.com/w3c/wcag21/issues/659<br />
<br />
=== 660 ===<br />
https://github.com/w3c/wcag21/issues/660<br />
<br />
=== 661 ===<br />
https://github.com/w3c/wcag21/issues/661<br />
<br />
=== 663 ===<br />
https://github.com/w3c/wcag21/issues/663 (Answer by Detlev)<br />
<br />
Thank you for your suggestion. We agree that your addition clarifies the text of SC 2.5.1 Pointer gestures. Path-based gestures are often carried out with a single pointer (as in drag-and-drop) so including an explicit reference ("...can be operated with a single pointer ''without a path-based gesture''") leaves less room for misunderstanding.<br />
<br />
=== 665 ===<br />
https://github.com/w3c/wcag21/issues/665<br />
<br />
=== 666 ===<br />
https://github.com/w3c/wcag21/issues/666<br />
<br />
=== 667 ===<br />
https://github.com/w3c/wcag21/issues/667<br />
<br />
=== 668 ===<br />
https://github.com/w3c/wcag21/issues/668<br />
<br />
=== 669 ===<br />
https://github.com/w3c/wcag21/issues/669<br />
<br />
=== 670 ===<br />
https://github.com/w3c/wcag21/issues/670<br />
<br />
=== 671 ===<br />
https://github.com/w3c/wcag21/issues/671<br />
<br />
Proposed response: (from AWK)<br />
Thank you for the comment. We agree that your wording is easier to read and will make the change to the structure, although there are other changes that are being implemented (e.g. changing "touch" to "pointer") so the wording will not be exact.<br />
<br />
(Alternative answer by Detlev - sorry Andrew, I worked in the wrong section (completed issues) and did not see you had drafted this respose already)<br />
<br />
Thank you for your suggestion. We agree that the definition of target was hard to parse and needed updating. We have changed "touch action" to "pointer action" to cover all pointer input, not just touch. We have also simplified the text explaining that parts of a target covered by another target must be excluded in target size measurements. <br />
<br />
Pull request for revised definition of 'target': https://github.com/w3c/wcag21/pull/673<br />
<br />
=== 672 ===<br />
https://github.com/w3c/wcag21/issues/672<br />
<br />
== Issues that have been addressed ==<br />
<br />
=== 150 ===<br />
https://github.com/w3c/wcag21/issues/150 Assigned to Goodwitch:<br />
<br />
Proposed Response (by Goodwitch): Thanks for your comment, Scott. We think we have addressed your concerns in the latest version of this SC and the updated Understanding Document. <br />
<br />
SC Changes - In the first draft of WCAG 2.1 (20170228) the proposed SC text for Graphics Contrast had used "essential" in both the positive and in the negative (as part of an exception). Based on your feedback (and feedback from others) we refined this SC text to only use "essential" as part of the exception. This language is parallel to the way "essential" is used in WCAG 2.0 SC 1.4.5 Images of Text. <br />
<br />
Understanding Changes - Examples to clarify this SC have been created in the draft understanding document that is published here https://rawgit.com/w3c/wcag21/graphics-contrast/understanding/21/graphics-contrast.html More examples and sufficient techniques will continue to be added to further enhance understandability and consistency in testing.<br />
<br />
=== 601 ===<br />
https://github.com/w3c/wcag21/issues/601 Assigned to JOC:<br />
<br />
Proposed Response (by JOC): <br />
Thank you for your observation. We believe that you refer to section 7.1 Common Control Purposes" https://www.w3.org/TR/WCAG21/#control-purposes. The Working Group will add a item to represent "skip to" links.<br />
<br />
<br />
=== 602 ===<br />
https://github.com/w3c/wcag21/issues/602<br />
<br />
Proposed Response (by AWK): <br />
The list of purposes is explicitly not requiring that the author use the specific text to identify a purpose, so adding the requirement to use the listed name is different than what we intended. For example, the "Table of Contents" purpose may be referenced using a different term depending on whether the author is incorporating metadata from one schema or another - one schema might use "toc" and another might use "tableOfContents" but as long as they are aligned with the purpose expressed in the list (and as long as there is accessibility support) either would be sufficient.<br />
<br />
=== 608 ===<br />
https://github.com/w3c/wcag21/issues/608<br />
<br />
Proposed response (from AWK): <br />
<br />
We are closing this issue as it is redundant to issue #609.<br />
<br />
=== 609 ===<br />
https://github.com/w3c/wcag21/issues/609<br />
<br />
Proposed response (from AWK): <br />
<br />
We are happy to make the changes from "which" to "that" for the WCAG 2.1 SC, glossary definitions, and within the "common purposes" section in order to make the guidelines more clear. We cannot change all of the suggested items, including boilerplate text and text within WCAG 2.0 glossary items. The main change needed to make it clear that sentence parts now starting with "which" are restrictive clauses is dropping the comma. The comma will be removed in cases where we need restrictive clauses.<br />
<br />
=== 613 ===<br />
https://github.com/w3c/wcag21/issues/613<br />
<br />
Editorial. Closed by AWK<br />
<br />
=== 614 ===<br />
https://github.com/w3c/wcag21/issues/614<br />
<br />
Editorial. Fixed and closed by AWK<br />
<br />
=== 615 ===<br />
https://github.com/w3c/wcag21/issues/615<br />
<br />
Editorial. Fixed and closed by AWK<br />
<br />
=== 616 ===<br />
https://github.com/w3c/wcag21/issues/616<br />
<br />
Proposed response (from AWK):<br />
<br />
The Working Group made the decision to not modify existing SC from WCAG 2.0, which is why these requirements are in a new SC. If you have any suggestions for an SC title that would address your concerns, please suggest it.<br />
<br />
=== 617 ===<br />
https://github.com/w3c/wcag21/issues/617<br />
<br />
Proposed response (from AWK):<br />
<br />
We agree that there is a potential for confusion, and have made a change to the SC text to read:<br />
<br />
"User Interface Components: Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;"<br />
<br />
=== 618 ===<br />
https://github.com/w3c/wcag21/issues/618<br />
<br />
Proposed response (by AWK): <br />
<br />
The first two items in your comment are editorial and have been changed as suggested. Regarding the comment about the use of "social Security" we will change the SC text to use your suggestion of "National identification number" as follows:<br />
<br />
"Authentication process involves basic personal identification information to which the user has easy access, such as name, address, email address, and National identification number."<br />
<br />
=== 619 ===<br />
https://github.com/w3c/wcag21/issues/619 Assigned to JOC and Detlev<br />
<br />
Proposed WG response (Detlev)<br />
<br />
Thank you for your suggestion. We agree that for interactions that include activation by positioning the device in a particular geographic location (your virtual fountain example), the requirement to provide alternative means of input does not apply. However, pointing a phone in the direction of a virtual location would still be a problem for a user with a motor impairment or a mounted device, so this would not negate the need for keyboard/pointer-accessible alternative modes of input. We believe the provision of alternative accommodations like the one you suggest could be included in a future SC focused on the use scenario of AR / Vr applications, and we are marking this issue as "defer" to ensure that it is reviewed at an appropriate time.<br />
<br />
=== 630 ===<br />
https://github.com/w3c/wcag21/issues/630 (Answer by Mike Gower)<br />
<br />
> I find this really confusing and would like some examples to illustrate these criteria.<br />
<br />
The Understanding document is in the process of being updated, and will offer examples and clarity. The current draft provides some explanation and [Examples](https://w3c.github.io/wcag21/understanding/21/content-on-hover-or-focus.html)<br />
<br />
> If there must be a mechanism to dismiss content without moving the pointer or keyboard focus, what might that look like? <br />
<br />
The normal mechanism for dismissing any kind of overlay is the Escape key; if that is implemented, this first bulleted requirement is met. Note that the wording of the SC does not prevent an author from adding in a mouse-equivalent affordance for this (such as simply moving away from the trigger/new content or hitting a close button displayed as a ‘x’ in the upper right corner of the overlay). The SC simply requires that there be a method that does not involve moving the mouse.<br />
<br />
> Most mechanisms to dismiss content ask that the user click on a button, which requires moving the pointer or keyboard focus.<br />
<br />
> What is the benefit to being able to hover over additional content that only appears on hover?<br />
<br />
The specific reason for a requirement to dismiss the on-hover overlay without moving the mouse, involves low vision users or users with reduced fine motor skills. Low vision users with a substantial level of magnification have a limited viewport. If they accidentally trigger new content with hover, they need to be able to dismiss that new content without losing their current point of regard. Otherwise, they are put in the situation where they must move their entire viewport away from the location they wished to interact with in order to dismiss the new unwanted content. After re-orienting themselves back again after the new content disappears, they then may accidentally trigger the hover again, repeating the same experience. Similarly, a user who cannot easily control the mouse and so is more prone to accidental triggering of on-hover content, needs a method of easily dismissing that is not mouse based.<br />
<br />
As will be made clear in the Understanding document, this SC is not recommending or encouraging the use of On Hover or On Focus as the trigger for displaying new content. This is considered a poor interaction by many, since users may easily inadvertently trigger new content. However, where an author elects to employ On Hover as a trigger, this SC places requirements on the implementation which make the resulting experience more accessible.</div>Dmacdonahttps://www.w3.org/WAI/GL/wiki/index.php?title=Draft_Responses_to_Dec_WD_Issues&diff=9075Draft Responses to Dec WD Issues2018-01-10T18:02:04Z<p>Dmacdona: /* 631 */</p>
<hr />
<div>== This page contains draft responses to issues logged in GitHub ==<br />
Open issues: https://github.com/w3c/wcag21/labels/Dec%20WD%20Comment<br />
<br />
If your issue is not listed, please add it as a heading 3 and make sure to indicate who drafted the response. See below for examples to follow in terms of organization of the information.<br />
<br />
Please write the responses in a way that can be easily copied/pasted into the issue. For each issue the editors will add "Official WG response: Thank you for your comment." to the start, so it isn't necessary to include that in the response.<br />
<br />
When an item is approved by the WG it will be indicated in the heading.<br />
<br />
=== 261 ===<br />
https://github.com/w3c/wcag21/issues/261 <br />
<br />
Proposed response (from AWK):<br />
Thank you for your comment. Since your comment was logged we have changed the SC and definition of target and we believe that your concerns are addressed. First, we are changing the first sentence of the definition to:<br />
<br />
Region of the display that will accept a pointer action, such as the interactive area of a user interface component.<br />
<br />
Second, regarding the concern about inline content such as footnotes, we now have an exception for links in a sentence or block of text.<br />
<br />
We hope that these address your concerns.<br />
<br />
<br />
=== 408 ===<br />
https://github.com/w3c/wcag21/issues/408<br />
<br />
Proposed Response (by AWK): Thank you for the comment. The use of "essential" in WCAG 2.1 is needed in some of the new SC as a way to convey an exception for content that must be presented in a specific manner and it is useful to make consistent use of the defined term for this purpose. In the SC identified the term essential refers to the specific way a graphic is presented, rather than the graphic itself being essential. We will clarify this in the understanding document.<br />
<br />
"Essential" is a defined term in WCAG, meaning "if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform".<br />
<br />
=== 520 ===<br />
https://github.com/w3c/wcag21/issues/520<br />
<br />
Proposed Response (by AWK): Thank you for the comment.<br />
<br />
You make four main points:<br />
# The WCAG development process excludes people with intellectual or learning disabilities<br />
# Request for three new Success Criteria and a glossary item<br />
#* Navigation to plain language summary<br />
#* Plain language summary<br />
#* Plain language summary of main pages<br />
# Request for modification of SC 3.1.2<br />
# WCAG 2.1 doesn’t include measures for people with intellectual and learning disabilities<br />
<br />
It has been very important to the Working Group that people with various types of cognitive disabilities are included in the work of the group. We formed a task force for cognitive accessibility and welcomed many new members into the working group, many of whom either have some type of cognitive disability or work regularly on the topic. There is no question that the process of developing a specification with a group of almost 100 people providing input can be taxing due to the volume of email, wiki page updates, and spec updates that take place, but the W3C and the Working Group are committed to supporting the needs of any group members to help ensure that it is possible for anyone to participate to the greatest extent possible. Still, we recognize that there is always room for improvement and are open to any suggestions you may have. Although our COGA task force did a significant amount of [https://www.w3.org/TR/coga-user-research/ background research], and an extensive [https://www.w3.org/TR/2017/WD-coga-gap-analysis-20171207/ Gap Analysis], it appears that a Success Criteria for a Plain Language Summary as found in your comment was not proposed by any stakeholders in the timeframe for WCAG 2.1. However, there is a proposed Success Criteria called [https://www.w3.org/TR/WCAG21/#identify-common-purpose Identify Common Purpose] which may allow personalization and simplification of interfaces.<br />
<br />
Regarding the inclusion of requirements for people with intellectual and learning disabilities, while we agree that the set of Success Criteria does not address every possible improvement that end users might benefit from, there are substantial challenges to ensure they meet the following acceptance criteria for Success Criteria both in WCAG 2.0 and 2.1:<br />
<br />
* Be testable through automated or manual processes.<br />
* Apply to all content (including many human languages - internationalization) unless preconditions for the application of the success criteria are explicitly identified.<br />
* Apply across technologies to the greatest extent possible. (Technology-specific issues should usually be addressed in Techniques.)<br />
* Have Success Techniques which demonstrate that each Success Criterion is implementable, using readily-available formats, user agents, and assistive technologies.<br />
See: https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteria. <br />
<br />
These are some of the core requirements for Success Criteria that are very important but do set a challenging bar for new criteria to meet. If Success Criteria are included that do not meet these requirements there is a strong risk that WCAG 2.1 might not gain consensus or might not be adopted. Of the currently 18 new Success Criteria, approximately half are viewed as providing some benefit for users with cognitive disabilities. <br />
<br />
We should also mention that WCAG 2.0 [http://www.davidmacd.com/blog/wcag-for-low-vision-cognitive-disabilites.html provides important help for people with cognitive and learning disabilities]. We hope that there will be significant advances in Assistive Technology for people with cognitive and learning disabilities in the future, which may facilitate further WCAG requirements upon authors and leverage more of the the existing requirements.<br />
<br />
==== Suggested new Success Criteria "Navigation to plain language summary" ====<br />
<br />
The deadline for introducing new Success Criteria closed over the summer as a result of the tight Working Group Charter timeline. However, we will mark this issue with a label (“defer”) to ensure that we can review these at the right time when we are able to review new proposals. This also impacts the suggestion for a definition since that definition is related to the proposed new criteria.<br />
<br />
We can provide it to the Cognitive Task Force (COGA) for consideration in a future version. It would impact the most important part of most web template designs and we expect there would be significant response from industry, so any objective research and studies your team can provide may help the COGA team with justifying this UI requirement universally across all web sites may be helpful.<br />
<br />
==== The suggested Amendment Success Criterion 3.1.2 Language of Parts ====<br />
<br />
Amending existing WCAG 2.0 Success Criteria is not permitted for WCAG 2.1 development, so in addition to the timeline consideration above, this suggestion would not be possible during this round of development.<br />
<br />
We can provide it to the Cognitive Task Force (COGA) for future consideration. In addition to the concerns about impact on site design, there is currently no assistive technology we know of that could make use of programmatically determined summaries in plain language. We suggest that this be demonstrated to the COGA team.<br />
<br />
==== Insert new Criterion 3.1.7: Plain Language Summary of site ====<br />
<br />
We extensively examined several proposals for plain language requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for an Success Criteria that could apply to "all content", and also there was some concern about requirements for freedom of expression. Regarding applying a plain language to a summary, these concerns may or may not be able to be overcome. <br />
<br />
We can provide it to the Cognitive Task Force (COGA) for future consideration.<br />
<br />
==== Ensure the summary page is clearly identified by a non-verbal icon. ====<br />
<br />
In addition to the timeline considerations above, we have had trouble gaining consensus on specific icons in the past. There are different cultures and different environments which may or may not approve of a particular icon design. We know of no such internationally recognized icon. WCAG strives to apply across the entire web to all countries and all languages, and so we'd like to hear about how we can ensure that a requirement for an icon could meet this need.<br />
<br />
==== Insert new term in Glossary ====<br />
We extensively examined several proposals for "plain language" requirements in WCAG 2.1. We went through many iterations and we were unable to find a way that they could meet the internationalization requirements for a Success Criteria. Also, there was some concern about requirements for freedom of expression.<br />
<br />
There is a strong possibility that there are ideas that the Working Group has simply not considered yet. Fortunately, the Working Group is committed to updating the specification far more rapidly than has been done in the past (targeting every 2 years), so these ideas and others will be able to be considered more fully in the near future.<br />
<br />
=== 589 === <br />
https://github.com/w3c/wcag21/issues/589<br />
<br />
Proposed response (AWK):<br />
Thank you for your comment. We understand your concern about PDF/UA including requirements that are unrelated to reflow in a PDF document. The possible technique has not been drafted or approved, so we appreciate your feedback. It is important to point out that techniques are not required, but they are sufficient, so if a PDF/UA conforming document would always meet the reflow requirements, we could make a technique that clarified this connection, but we would undoubtedly include other techniques as well that would allow a PDF to meet the reflow SC without conforming to PDF/UA.<br />
<br />
Of course, as you indicate, to include a PDF/UA-related technique we would need to consider the testing questions you mention and more.<br />
<br />
We have work to do to ensure that the understanding and techniques documents are up to date and accurate, but it is worth mentioning that the plan moving forward is that the non-normative techniques and understanding documents will be able to be updated continuously in the event that new information or errors are identified.<br />
<br />
=== 605 === <br />
https://github.com/w3c/wcag21/issues/605 Assigned to JOC:<br />
<br />
Proposed response (by Mike Gower):<br />
<br />
The initial goal of this SC was broader in scope but various considerations were identified which led the authors to keep the scope contained. Instead the intention is to list Best Practices and Advisory Techniques which could address broader Changes of Content. To that end, the SC language will not be changed.<br />
<br />
Here are specific responses to some of the points raised in the issue:<br />
<br />
> addresses the implementation of status messages, but doesn't say there needs to be a status message (essentially you can pass by not having a status message)<br />
<br />
That is by design. WCAG has a history of defining content requirements when the content is ''present''.<br />
<br />
Any attempt to make status messages a requirement will inevitably lead to poor implementations that make applications unusable by screen reader users -- the exact opposite of the goal. It was felt that significant scrutiny is given by designers to information they add to the UI. Restricting the SC to cover such information, where it does not alter a user's context (no change of context), seemed like a way to ensure messages were appropriate and limited.<br />
<br />
> indicates that the info be presented by AT without receiving focus<br />
<br />
That is not exactly what the SC is saying. It defines status messages as items that do not take focus (change of content without being a change of context), and _then_ makes requirements where such items exist. The SC does not restrict messages from being displayed in a dialog, for example. Such a message is a change of context and so does not meet the definition of a status message, and so is not covered by it (being instead covered by 4.1.2).<br />
<br />
> The need (and reasonable implementation) is not limited to markup languages... An interactive book implemented in Swift or Objective-C for iOS can certainly easily provide notification through AT, for example.<br />
<br />
The working group spent considerable time debating removing the markup language restriction. In the end, the group felt there is not enough research, evidence or best practices to apply this to other technologies. WCAG 2.0 and 2.1 apply to content at a URL. However, we'd be glad to have you propose a technique for how to apply this to other technologies that we could add as a best practice for those who may be trying to apply WCAG to content not at a URL.<br />
<br />
> If a change of content causes new content or functionality to appear on the screen, at least one of the following is true:<br />
<br />
We believe this effectively means "For each change of content at least one of the following is true:" We had several iterations with a similar approach to this, covering similar scenarios. All were abandoned due to nuances of implementation or testing. Some of those have been identified below.<br />
<br />
> The new content appears directly after the control that triggers it in the reading order.<br />
<br />
If the new content is a user interface control, this will likely be detected by screen readers. (Although issues with latency can cause focus issues; for example, where the user's act of leaving a control triggers a change, the user's focus may move to the next existing item before coding updates the DOM, thus the user bypasses the new control.)<br />
<br />
But what if the new content is an element that does not take focus? If the screen reader user has previously perused the page and is now navigating by pressing Tab, how is the screen reader user to know the new information exists? Since an author could use this bullet to bypass notifying users (the first bullet), it seems to lose a key accomplishment of the current SC language.<br />
<br />
> For content that is updated on a regular basis, or is updated so frequently that status messages may be disruptive, the user is advised of the type and frequency of updates (e.g. through a section heading or label)<br />
<br />
These "regular basis" and "disruptive" parameters would have to be defined in a way that was testable. The manner of advising the user would itself be quite difficult to establish in language that ensured it was testable. There is danger that this would be poorly implemented and would degrade the experience for a screen reader user. Perhaps in future iterations of WCAG we can find standardized and testable ways of notifying users of content that updates frequently without this risk of interfering with their experience.<br />
<br />
Some examples of interactions which may not be covered/considered by your alternative proposal:<br />
<br />
- chat clients and other dynamic interactive content where the content changes are related to the primary page but not ultimately initiated by the user<br />
<br />
- twitter feeds and other updating content whose frequency of change and nature of content changes can vary markedly based on parameters beyond the author's control or ability to predict accurately.<br />
<br />
- existing content that is altered rather than content that is added (e.g., the items in a select is updated based on a user's chosen value in a control, such as the choice of a country updating the values in the "State/province" select)<br />
<br />
=== 620 ===<br />
https://github.com/w3c/wcag21/issues/620 Related question asked by JOC, awaiting response and will then draft response: Assigned to JOC<br />
<br />
Proposed WG response (Detlev)<br />
<br />
Thank you for your comment. You propose to remove 'user motion' to exclude situations where the user is moving and the device just observing. The aim of the user motion part of the SC was to address motions like hand gestures that are observed by the camera or other sensors that can trigger certain events (such as forwarding a presentation, or panning a view). We will qualify 'user motion' to mean explicit actuation in the context of this SC, and add to the understanding document to describe that scenarios where the user moves without explixitly actuating content (as in you your Leap Motion example) are not in scope of this SC.<br />
<br />
=== 621 ===<br />
https://github.com/w3c/wcag21/issues/621<br />
Question asked by JOC, awaiting response and will then draft response: Assigned to JOC and Detlev<br />
<br />
Proposed response (Detlev)<br />
<br />
Thank you for your comment. You raise two issues - one is splitting device motion and user motion into separate SCs, the second is making us aware of a third type of similar functionality, that of motion / events in the field of view of the device (device is observing). We agree that this is a separate issue and potentially, a separate SC. In this SC, the issue is active, purposeful user input.<br />
Your argument for creating two distinct SCs is that the requirements and techniques for user motion and device motion might evolve in different ways. This might be correct, but currently they would both require some alternative way of input that can be actuated via the keyboard interface (including speech input, switch etc.) and a pointer interface. We believe that the SC Motion Actuation addresses broadly issues common to both user and device motion (difficulty of intentional motion in the way required for input via sensors, possibly because of a motor impairment, possibly because the device is mounted), and that they can therefore be treated in one SC.<br />
<br />
=== 622 ===<br />
https://github.com/w3c/wcag21/issues/622 Assigned to Detlev<br />
<br />
Proposed response (Detlev)<br />
<br />
Thank you for your comment. You describe usage scenarios where input happens not via a particular user motion, but via the position or orientation of the device. This issue is likely to become more important with the spread or AR / VR use scenarios. However, we believe it can be separated from the use case of motion actuation where motion is relative to the device and the exact position (e.g. on the z-axis, distance to ground) seems less relevant. The case of orientation (no position lock unless by user choice, content adapts to user-chosen orientation) seems already addressed by the SC 2.6.2 Orientation.<br />
<br />
You raise an interesting issue when you talk of alternatives other than user interface controls that still use motion but adapt in other ways (e.g., by lowering AR / VR objects for wheelchair users), motivated by the aim to not negate the full experience for wheelchair users (and many others). While different accommodations are certainly useful and should be encouraged, they would not negate the need for a means of input that works with keyboard and pointer interfaces. (An analogy might be sign language: Having a sign language version of a video talk is great, but it does not negate the requirement for captions.) You make the point that in the future, the availability of those other accommodations might be the difference between participation and exclusion (through exceptions) from entire categories of software. Requirements for alternative accommodations would be a good subject for a future SC as these technologies become more mature and widespread. We are open to suggestions to include additional techniques as optional best practices in the understanding document. Can you provide a description and examples that could be used?<br />
<br />
=== 624 ===<br />
https://github.com/w3c/wcag21/issues/624<br />
<br />
Thank you for your comment. It is hard to make changes to the list at this point, However, these are not the terms that need to be used, just the concepts that need to be addressed. In other words, the vocabulary you are using can use a term "new" and conform. <br />
<br />
You are also invited to comment on the personalization task force and open an issue to suggest any term changes there, which we know would be very welcome. (see https://github.com/w3c/personalization-semantics/issues)<br />
<br />
=== 628 ===<br />
https://github.com/w3c/wcag21/issues/628<br />
<br />
=== 629 ===<br />
https://github.com/w3c/wcag21/issues/629<br />
<br />
Thank you for your feedback. You are correct - will also be able to use an aria vocabulary that is being produced. (https://w3c.github.io/personalization-semantics/content/index.html)<br />
The current version of the understanding document identifies different ways to meet the success criteria and the new draft of the understanding document gives alternative ways to meet each item in the list.<br />
<br />
To make sure the success criteria are sufficiently mature we will be adding techniques and ensure that there are implementations and user-agent support before we leave CR as per our exit criteria - see https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria<br />
<br />
=== 631 ===<br />
https://github.com/w3c/wcag21/issues/631 . (Answer by David MacDonald)<br />
<br />
Thank you for your question. This Success Criteria was developed in the Mobile Task Force with the primary purpose to ensure that pointer targets are large enough for people with dexterity disabilities to hit the touch target in mobile, with the additional benefit of providing larger click targets for mouse users on desktop who have dexterity disabilities. This was not covered in WCAG 2.0. The task force looked at a number of studies and other standards, such as the BBC Mobile Guidelines. One study demonstrated that some people with dexterity disabilities needed a target size of 100px by 100px. So we knew that we could only provide a minimum value and encourage the author to make targets as large as possible. The idea of the minimum size requirement in the success criteria was to choose a value as large as possible without negatively impacting design. Google mobile developer guidelines recommended 48px by 48px. Apple's mobile recommendation was 44px by 44px. We took Apple's recommendation and removed one dimension in response to comments that 44px by 44px was too large for many interfaces, especially vertical lists of text links, and we added a list of exceptions. We expect that the other dimension not required in the Success Criteria will be at least the default row height in right to left languages. We feel 44px in one direction strikes the right balance. The intent is that users with mild to moderate dexterity disabilities can hit this minimum target without zooming, while users who need a very large target would likely have to zoom in.<br />
<br />
=== 634 ===<br />
https://github.com/w3c/wcag21/issues/634<br />
<br />
=== 635 ===<br />
https://github.com/w3c/wcag21/issues/635 (answer from Lisa)<br />
<br />
Thanks for the feedback. We have written an understanding document and will be drafting techniques that explain this.<br />
The current version of the understanding document identifies different ways to meet the success criteria and the new draft of the understanding document gives alternative ways to meet each item in the list.<br />
<br />
It is worth noting that success criteria specify what needs to be done but are never technology specific. How to reach them or what terms to use is always left to techniques. There are often more than one way to achieve success (such as using native html, xforms or ARIA)<br />
<br />
=== 636 ===<br />
https://github.com/w3c/wcag21/issues/636 (answer by Lisa) <br />
<br />
The new wording just requires that the purpose is programmatically determined. We will be adding techniques and have user agent support before we leave CR as per are exit criteria - see https://www.w3.org/WAI/GL/wiki/WCAG_2.1_CR_Exit_Criteria.<br />
<br />
It is worth noting that success criteria specify what needs to be done but are never technology specific. How to reach them or what terms to use is always left to techniques. There are often more than one way to achieve success (such as using native html, xforms or ARIA)<br />
<br />
=== 637 ===<br />
https://github.com/w3c/wcag21/issues/637<br />
<br />
=== 644 ===<br />
https://github.com/w3c/wcag21/issues/644 (Assigned to Laura):<br />
<br />
Proposed response:<br />
<br />
Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:<br />
<br />
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."<br />
<br />
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.<br />
<br />
We will also clarify the applicability of this SC in the Understanding document.<br />
<br />
=== 649 ===<br />
https://github.com/w3c/wcag21/issues/649<br />
<br />
=== 650 ===<br />
https://github.com/w3c/wcag21/issues/650 . (Answer:David MacDonald)<br />
<br />
It asks if tabbed interfaces are covered in hover or focus SC.<br />
Analysis: There is a discussion [https://lists.w3.org/Archives/Public/w3c-wai-gl/2018JanMar/subject.html here] Scroll down to Issue 650. <br />
Alastair asked if we can we pick up on the ‘additional’ part of: “…keyboard focus triggers additional content to become visible” A tab set switches content, it doesn’t show additional content.<br />
David said: Can put that in understanding content but might need normative language to distinguish additional from switching. Opens another question. If users don't move their mouse to dismiss popup, how are they expected to dismiss it.... with the keyboard? If so, why not just say that? <br />
<br />
Need to resolve before proceeding with a response.<br />
<br />
=== 651 ===<br />
https://github.com/w3c/wcag21/issues/651<br />
<br />
=== 653 ===<br />
https://github.com/w3c/wcag21/issues/653<br />
<br />
=== 654 ===<br />
https://github.com/w3c/wcag21/issues/654<br />
<br />
=== 655 ===<br />
https://github.com/w3c/wcag21/issues/655<br />
<br />
Proposed response (AWK):<br />
Thank you for your comment. The language suggested doesn't fully account for the intent of the exception as currently written since the exception is covering both that the ... (needs more work)<br />
<br />
=== 656 ===<br />
https://github.com/w3c/wcag21/issues/656<br />
<br />
Proposed response (AC):<br />
Thank you for your comment, we have integrated a change to avoid issues with PDF and application scenarios, so the SC text starts:<br />
<br />
"In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property."<br />
<br />
The purpose of the SC is to encourage people to enable over-riding of content via user-agent mechanisms, rather than require on-page widgets. Therefore the working group would like to avoid 'mechanism is available' language for this SC as people tend to read it as meaning adding a widget to a page.<br />
<br />
=== 657 ===<br />
https://github.com/w3c/wcag21/issues/657<br />
<br />
=== 659 ===<br />
https://github.com/w3c/wcag21/issues/659<br />
<br />
=== 660 ===<br />
https://github.com/w3c/wcag21/issues/660<br />
<br />
=== 661 ===<br />
https://github.com/w3c/wcag21/issues/661<br />
<br />
=== 663 ===<br />
https://github.com/w3c/wcag21/issues/663 (Answer by Detlev)<br />
<br />
Thank you for your suggestion. We agree that your addition clarifies the text of SC 2.5.1 Pointer gestures. Path-based gestures are often carried out with a single pointer (as in drag-and-drop) so including an explicit reference ("...can be operated with a single pointer ''without a path-based gesture''") leaves less room for misunderstanding.<br />
<br />
=== 665 ===<br />
https://github.com/w3c/wcag21/issues/665<br />
<br />
=== 666 ===<br />
https://github.com/w3c/wcag21/issues/666<br />
<br />
=== 667 ===<br />
https://github.com/w3c/wcag21/issues/667<br />
<br />
=== 668 ===<br />
https://github.com/w3c/wcag21/issues/668<br />
<br />
=== 669 ===<br />
https://github.com/w3c/wcag21/issues/669<br />
<br />
=== 670 ===<br />
https://github.com/w3c/wcag21/issues/670<br />
<br />
=== 671 ===<br />
https://github.com/w3c/wcag21/issues/671<br />
<br />
Proposed response: (from AWK)<br />
Thank you for the comment. We agree that your wording is easier to read and will make the change to the structure, although there are other changes that are being implemented (e.g. changing "touch" to "pointer") so the wording will not be exact.<br />
<br />
(Alternative answer by Detlev - sorry Andrew, I worked in the wrong section (completed issues) and did not see you had drafted this respose already)<br />
<br />
Thank you for your suggestion. We agree that the definition of target was hard to parse and needed updating. We have changed "touch action" to "pointer action" to cover all pointer input, not just touch. We have also simplified the text explaining that parts of a target covered by another target must be excluded in target size measurements. <br />
<br />
Pull request for revised definition of 'target': https://github.com/w3c/wcag21/pull/673<br />
<br />
=== 672 ===<br />
https://github.com/w3c/wcag21/issues/672<br />
<br />
== Issues that have been addressed ==<br />
<br />
=== 150 ===<br />
https://github.com/w3c/wcag21/issues/150 Assigned to Goodwitch:<br />
<br />
Proposed Response (by Goodwitch): Thanks for your comment, Scott. We think we have addressed your concerns in the latest version of this SC and the updated Understanding Document. <br />
<br />
SC Changes - In the first draft of WCAG 2.1 (20170228) the proposed SC text for Graphics Contrast had used "essential" in both the positive and in the negative (as part of an exception). Based on your feedback (and feedback from others) we refined this SC text to only use "essential" as part of the exception. This language is parallel to the way "essential" is used in WCAG 2.0 SC 1.4.5 Images of Text. <br />
<br />
Understanding Changes - Examples to clarify this SC have been created in the draft understanding document that is published here https://rawgit.com/w3c/wcag21/graphics-contrast/understanding/21/graphics-contrast.html More examples and sufficient techniques will continue to be added to further enhance understandability and consistency in testing.<br />
<br />
=== 601 ===<br />
https://github.com/w3c/wcag21/issues/601 Assigned to JOC:<br />
<br />
Proposed Response (by JOC): <br />
Thank you for your observation. We believe that you refer to section 7.1 Common Control Purposes" https://www.w3.org/TR/WCAG21/#control-purposes. The Working Group will add a item to represent "skip to" links.<br />
<br />
<br />
=== 602 ===<br />
https://github.com/w3c/wcag21/issues/602<br />
<br />
Proposed Response (by AWK): <br />
The list of purposes is explicitly not requiring that the author use the specific text to identify a purpose, so adding the requirement to use the listed name is different than what we intended. For example, the "Table of Contents" purpose may be referenced using a different term depending on whether the author is incorporating metadata from one schema or another - one schema might use "toc" and another might use "tableOfContents" but as long as they are aligned with the purpose expressed in the list (and as long as there is accessibility support) either would be sufficient.<br />
<br />
=== 608 ===<br />
https://github.com/w3c/wcag21/issues/608<br />
<br />
Proposed response (from AWK): <br />
<br />
We are closing this issue as it is redundant to issue #609.<br />
<br />
=== 609 ===<br />
https://github.com/w3c/wcag21/issues/609<br />
<br />
Proposed response (from AWK): <br />
<br />
We are happy to make the changes from "which" to "that" for the WCAG 2.1 SC, glossary definitions, and within the "common purposes" section in order to make the guidelines more clear. We cannot change all of the suggested items, including boilerplate text and text within WCAG 2.0 glossary items. The main change needed to make it clear that sentence parts now starting with "which" are restrictive clauses is dropping the comma. The comma will be removed in cases where we need restrictive clauses.<br />
<br />
=== 613 ===<br />
https://github.com/w3c/wcag21/issues/613<br />
<br />
Editorial. Closed by AWK<br />
<br />
=== 614 ===<br />
https://github.com/w3c/wcag21/issues/614<br />
<br />
Editorial. Fixed and closed by AWK<br />
<br />
=== 615 ===<br />
https://github.com/w3c/wcag21/issues/615<br />
<br />
Editorial. Fixed and closed by AWK<br />
<br />
=== 616 ===<br />
https://github.com/w3c/wcag21/issues/616<br />
<br />
Proposed response (from AWK):<br />
<br />
The Working Group made the decision to not modify existing SC from WCAG 2.0, which is why these requirements are in a new SC. If you have any suggestions for an SC title that would address your concerns, please suggest it.<br />
<br />
=== 617 ===<br />
https://github.com/w3c/wcag21/issues/617<br />
<br />
Proposed response (from AWK):<br />
<br />
We agree that there is a potential for confusion, and have made a change to the SC text to read:<br />
<br />
"User Interface Components: Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;"<br />
<br />
=== 618 ===<br />
https://github.com/w3c/wcag21/issues/618<br />
<br />
Proposed response (by AWK): <br />
<br />
The first two items in your comment are editorial and have been changed as suggested. Regarding the comment about the use of "social Security" we will change the SC text to use your suggestion of "National identification number" as follows:<br />
<br />
"Authentication process involves basic personal identification information to which the user has easy access, such as name, address, email address, and National identification number."<br />
<br />
=== 619 ===<br />
https://github.com/w3c/wcag21/issues/619 Assigned to JOC and Detlev<br />
<br />
Proposed WG response (Detlev)<br />
<br />
Thank you for your suggestion. We agree that for interactions that include activation by positioning the device in a particular geographic location (your virtual fountain example), the requirement to provide alternative means of input does not apply. However, pointing a phone in the direction of a virtual location would still be a problem for a user with a motor impairment or a mounted device, so this would not negate the need for keyboard/pointer-accessible alternative modes of input. We believe the provision of alternative accommodations like the one you suggest could be included in a future SC focused on the use scenario of AR / Vr applications, and we are marking this issue as "defer" to ensure that it is reviewed at an appropriate time.<br />
<br />
=== 630 ===<br />
https://github.com/w3c/wcag21/issues/630 (Answer by Mike Gower)<br />
<br />
> I find this really confusing and would like some examples to illustrate these criteria.<br />
<br />
The Understanding document is in the process of being updated, and will offer examples and clarity. The current draft provides some explanation and [Examples](https://w3c.github.io/wcag21/understanding/21/content-on-hover-or-focus.html)<br />
<br />
> If there must be a mechanism to dismiss content without moving the pointer or keyboard focus, what might that look like? <br />
<br />
The normal mechanism for dismissing any kind of overlay is the Escape key; if that is implemented, this first bulleted requirement is met. Note that the wording of the SC does not prevent an author from adding in a mouse-equivalent affordance for this (such as simply moving away from the trigger/new content or hitting a close button displayed as a ‘x’ in the upper right corner of the overlay). The SC simply requires that there be a method that does not involve moving the mouse.<br />
<br />
> Most mechanisms to dismiss content ask that the user click on a button, which requires moving the pointer or keyboard focus.<br />
<br />
> What is the benefit to being able to hover over additional content that only appears on hover?<br />
<br />
The specific reason for a requirement to dismiss the on-hover overlay without moving the mouse, involves low vision users or users with reduced fine motor skills. Low vision users with a substantial level of magnification have a limited viewport. If they accidentally trigger new content with hover, they need to be able to dismiss that new content without losing their current point of regard. Otherwise, they are put in the situation where they must move their entire viewport away from the location they wished to interact with in order to dismiss the new unwanted content. After re-orienting themselves back again after the new content disappears, they then may accidentally trigger the hover again, repeating the same experience. Similarly, a user who cannot easily control the mouse and so is more prone to accidental triggering of on-hover content, needs a method of easily dismissing that is not mouse based.<br />
<br />
As will be made clear in the Understanding document, this SC is not recommending or encouraging the use of On Hover or On Focus as the trigger for displaying new content. This is considered a poor interaction by many, since users may easily inadvertently trigger new content. However, where an author elects to employ On Hover as a trigger, this SC places requirements on the implementation which make the resulting experience more accessible.</div>Dmacdona