Re: Patterns for to address requests for 'wider clickable area'
John Coburn <[email protected]> Fri, 29 May 2020 22:06:52 -0500
| Newsgroups | gmane.org.w3c.accessibility.general |
|---|---|
| Message-ID | <CAE=WnTkNN5aHzbHecZ9ZbN4B60HRYTGe0wciJeLN0FXtD2_CkA@mail.gmail.com> |
--00000000000051487705a6d4f4ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the stellar guidance, Steve! On Fri, May 29, 2020 at 5:28 PM Steve Green <[email protected]= > wrote: > We come across this quite often and it can work well if it is implemented > carefully. I recommend the following: > > > > 1. There must still be some sort of link or button to indicate that > the area is clickable. In UX terminology, there=E2=80=99s got to be an > =E2=80=9Caffordance=E2=80=9D. Leaving aside WCAG conformance, there ar= e at least two > practical reasons: > > 1. Screen magnifier users may easily fail to notice any instructions > you provide that say the whole row is clickable. Even if the area= =E2=80=99s style > changes on hover and focus, they won=E2=80=99t necessarily know thi= s means the area > is clickable. > > 2. Voice recognition software users need to know what keyword to > use to operate the links. In fact, they won=E2=80=99t even know the= areas are > clickable because they do not see the hover or focus states. User t= esting > shows that only a proportion of people read the instructions. > > 2. The clickable area must have a visible boundary. It=E2=80=99s re= ally > confusing if the cursor changes from a pointer to a hand or no apparen= t > reason in an empty area of the page. > > 3. The styling of the clickable area must change on hover and focus. > For WCAG conformance, it would be sufficient to just change the outlin= e > style. However, screen magnifier users may not see such a change depen= ding > on the size and shape of the area, so I advocate changing the backgrou= nd > colour too. > > > > You mention =E2=80=9CGroups of information wrapped in focusable, clickabl= e > block-level elements=E2=80=9D. You wouldn=E2=80=99t usually design it tha= t way. The group > of information would contain a link or button, typically at the end. Ther= e > would be hover, click and touch event handlers on the container that have > the same behaviour as the link or button, but it would not be in the focu= s > order and would not be exposed to assistive technologies. We have > implemented this many times and it works really well with assistive > technologies. > > > > Steve Green > > Managing Director > > Test Partners Ltd > > > > > > *From:* John Coburn <[email protected]> > *Sent:* 28 May 2020 20:49 > *To:* [email protected] > *Subject:* Patterns for to address requests for 'wider clickable area' > > > > Recently I've been seeing more requests and designs for "larger clickable > areas" Contrived example: say there's an 'export' table of data items wi= th > columns for each attribute and an actions column containing a single > "export" button - a per-item action - the design request would ask for th= e > entire row of the table to be clickable so they can presumably remove the > per-item button and save the column of real-estate. > > The somewhat wreckless "designer" half of me can't deny the improvement t= o > the "feel" of larger hit areas once I learn about it - but the a11y-minde= d > developer half asks 'how can we label this appropriately or set up the > expectations for that behavior with the assistive tech user ? How can we > keep from potentially hiding any of that important data within? > > Sometimes the layout of data is non-tabular (but could be) where the list > items themselves are comprised of key/value pairs and attributes of the > data item - way more text than a simple per-item 'export' button or > anything like that. Groups of information wrapped in focusable, clickable > block-level elements - it just seems cringe-worthy when I imagine > screen-reader navigation, but perhaps that's just a frivolous worry. > > > > Are there any go-to patterns/practices/guidelines anywhere for handling > this sort of thing? Or is the answer something terribly obvious? (Caption > text or some visible instructional comes to mind) I'm aware of > markup/syntax that could possibly *make it work - but much of that hardly > seems like 'best' practice - any help/advice appreciated. Thanks in advan= ce! > > Apologies for a lengthy message. > John Coburn > --00000000000051487705a6d4f4ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks for the stellar guidance, Steve!<br></div><br><div = class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 29,= 2020 at 5:28 PM Steve Green <<a href=3D"mailto:steve.green@testpartners= ..co.uk">[email protected]</a>> wrote:<br></div><blockquote = class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol= id rgb(204,204,204);padding-left:1ex"> <div lang=3D"EN-GB"> <div class=3D"gmail-m_3864962198229936288WordSection1"> <p class=3D"MsoNormal"><span>We come across this quite often and it can wor= k well if it is implemented carefully. I recommend the following:<u></u><u>= </u></span></p> <p class=3D"MsoNormal"><span><u></u>=C2=A0<u></u></span></p> <ol style=3D"margin-top:0in" start=3D"1" type=3D"1"> <li class=3D"gmail-m_3864962198229936288MsoListParagraph" style=3D"margin-l= eft:0in"><span>There must still be some sort of link or button to indicate = that the area is clickable. In UX terminology, there=E2=80=99s got to be an= =E2=80=9Caffordance=E2=80=9D. Leaving aside WCAG conformance, there are at least two practical reasons:<= br> <br> <u></u><u></u></span></li><ol style=3D"margin-top:0in" start=3D"1" type=3D"= a"> <li class=3D"gmail-m_3864962198229936288MsoListParagraph" style=3D"margin-l= eft:0in"><span>Screen magnifier users may easily fail to notice any instruc= tions you provide that say the whole row is clickable. Even if the area=E2= =80=99s style changes on hover and focus, they won=E2=80=99t necessarily know this means= the area is clickable.<br> <br> <u></u><u></u></span></li><li class=3D"gmail-m_3864962198229936288MsoListPa= ragraph" style=3D"margin-left:0in"><span>Voice recognition software users n= eed to know what keyword to use to operate the links. In fact, they won=E2= =80=99t even know the areas are clickable because they do not see the hover or focus states. User testing shows that= only a proportion of people read the instructions.<br> <br> <u></u><u></u></span></li></ol> <li class=3D"gmail-m_3864962198229936288MsoListParagraph" style=3D"margin-l= eft:0in"><span>The clickable area must have a visible boundary. It=E2=80=99= s really confusing if the cursor changes from a pointer to a hand or no app= arent reason in an empty area of the page.<br> <br> <u></u><u></u></span></li><li class=3D"gmail-m_3864962198229936288MsoListPa= ragraph" style=3D"margin-left:0in"><span>The styling of the clickable area = must change on hover and focus. For WCAG conformance, it would be sufficien= t to just change the outline style. However, screen magnifier users may not see such a change depending on the= size and shape of the area, so I advocate changing the background colour t= oo.<u></u><u></u></span></li></ol> <p class=3D"MsoNormal"><span><u></u>=C2=A0<u></u></span></p> <p class=3D"MsoNormal"><span>You mention =E2=80=9CGroups of information wra= pped in focusable, clickable block-level elements=E2=80=9D. You wouldn=E2= =80=99t usually design it that way. The group of information would contain = a link or button, typically at the end. There would be hover, click and touch event handlers on the co= ntainer that have the same behaviour as the link or button, but it would no= t be in the focus order and would not be exposed to assistive technologies.= We have implemented this many times and it works really well with assistive technologies.<u></u><u></u></span>= </p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <p class=3D"MsoNormal"><span>Steve Green<u></u><u></u></span></p> <p class=3D"MsoNormal"><span>Managing Director<u></u><u></u></span></p> <p class=3D"MsoNormal"><span>Test Partners Ltd<u></u><u></u></span></p> <p class=3D"MsoNormal"><span><u></u>=C2=A0<u></u></span></p> <p class=3D"MsoNormal"><span><u></u>=C2=A0<u></u></span></p> <p class=3D"MsoNormal"><b><span lang=3D"EN-US">From:</span></b><span lang= =3D"EN-US"> John Coburn <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> <br> <b>Sent:</b> 28 May 2020 20:49<br> <b>To:</b> <a href=3D"mailto:[email protected]" target=3D"_blank">w3c-wai-i= [email protected]</a><br> <b>Subject:</b> Patterns for to address requests for 'wider clickable a= rea'<u></u><u></u></span></p> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> <div> <p class=3D"MsoNormal">Recently I've been seeing more requests and desi= gns for "larger clickable areas"=C2=A0 Contrived example: say the= re's an 'export' table of data items with columns for each attr= ibute and an actions column containing a single "export" button - a per-item action - the design request would ask for the entire row of the= table to be clickable so they can presumably remove the per-item button an= d save the column of real-estate.<br> <br> The somewhat wreckless "designer" half of me can't deny the i= mprovement to the "feel" of larger hit areas once I learn about i= t - but the a11y-minded developer half asks 'how can we label this appr= opriately or set up the expectations for that behavior with the assistive tech user ? How can we keep=C2=A0from potentially hiding any= of that important data within?<br> <br> Sometimes the layout of data is non-tabular (but could be) where the list i= tems themselves are comprised of key/value pairs and attributes of the data= item - way more text than a simple per-item 'export' button or any= thing like that. Groups of information wrapped in focusable, clickable block-level elements - it just seems cringe-worthy= when I imagine screen-reader navigation, but perhaps that's just a fri= volous worry.<u></u><u></u></p> <div> <p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> </div> <div> <p class=3D"MsoNormal">Are there any go-to patterns/practices/guidelines an= ywhere for handling this sort of thing? Or is the answer something terribly= obvious? (Caption text or some visible instructional comes to mind) I'= m aware of markup/syntax that could possibly *make it work - but much of that hardly seems like 'best' practice= - any help/advice appreciated. Thanks in advance!<br> <br> Apologies for a lengthy message.<br> John Coburn<u></u><u></u></p> </div> </div> </div> </div> </blockquote></div> --00000000000051487705a6d4f4ae--