WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Scrolling Agree to Terms Screen

for

From: Isabel Holdsworth
Date: Sep 21, 2018 7:03AM

It would probably work, but one client insists on everyone scrolling
through the entire agreement.

I've come up with a fudge which involves adding a tabindex to all
direct children of the main container. When the last of these children
receives focus, the "I agree" button is enabled. This works well,
because screenreaders speak the content as the user tabs through each
clause or paragraph in the agreement.

I know that adding a tabindex to non-functional items is frowned upon,
but I hope it doesn't fail any WCAG2 SC, as it's the only compromise I
can come up with that works for everyone.

I used Glen's idea of not disabling the button so it can still receive
focus, and if the user clicks it before having scrolled through the
T&Cs, an error message is displayed explaining how to enable the
button.

I think this solution will be accepted by our client.

As always,, thanks for your insights and ideas. Have a great weekend.

Cheers, Isabel

On 21/09/2018, Swift, Daniel P. < <EMAIL REMOVED> > wrote:
> If I'm understanding this correctly, the sr-user doesn't need to scroll
> because the sr is reading and therefore the 'accept' button is never
> enabled. Much like Glen described, I would include directions at the top
> that are sr-only. In the directions, I would include "press [shortcut-key]
> to acknowledge that you agree". I would bind that short-cut key and use
> that to trigger the 'accept' button.
>
> Would that work?
>
> Dan Swift
> Senior Web Specialist
> Enterprise Services
> West Chester University
> 610.738.0589
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of Isabel Holdsworth
> Sent: Friday, September 21, 2018 5:14 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Scrolling Agree to Terms Screen
>
> Thanks Glen. I like the idea of using aria-disabled but still allowing the
> button to receive focus. But I think for sighted keyboard users there would
> need to be an error message if they tried to press it.
>
> But My issue is how to make the scrollable div itself accessible. If the
> focus is on a div full of HTML, screenreaders don't provide any feedback
> while the user is scrolling down, so it's not possible to know how far
> you've progressed through the agreement, or even to read it as you scroll.
> Without making the div editable, I don't know how to fix this.
>
> Any ideas anyone?
>
> On 20/09/2018, glen walker < <EMAIL REMOVED> > wrote:
>> Yeah, sometimes things are the way they are and we just have to make
>> what we have accessible even if we'd like to redesign it.
>>
>> In this case, perhaps you can do something like this:
>>
>> - The ACCEPT button could have an aria-label that explains a little
>> more
>> as to why the button is currently disabled. You could maybe put
>> this extra
>> information in aria-describedby, but jaws used to not announce the
>> text in
>> aria-describedby but instead would say "use jaws key plus alt plus m".
>> I
>> just tried it now and jaws actually read aria-describedby without
>> me having
>> to hit the shortcut key. Not sure if that's a recent change.
>> - Part of the ACCEPT additional info could say there's a link after
>> the
>> button that takes you to the terms and conditions, as a convenience.
>> The
>> link could be sr-only.
>> - The terms and conditions section could also have an aria-label that
>> explains that you have to scroll to the bottom to enable the ACCEPT
>> button. The T&C could be a complementary role or a <section> element.
>>
>> The code would (very) roughly be something like:
>>
>> <div id="terms" tabindex="0" role="complementary" aria-label="terms
>> and conditions, you must scroll to the bottom of this section to
>> enable the accept button"> blah blah blah </div>
>>
>> <button aria-label="accept. you must scroll to the bottom of the terms
>> and conditions section before the accept button is enabled. a link to
>> the terms and conditions is after this button">accept</button>
>>
>> <a href="#terms" class="sr-only">go to terms and conditions</a>
>>
>> Depending on your requirements, the button could use the disabled
>> attribute, truly making the button disabled (and making legal happy)
>> but AT users would have to walk the DOM (or use the 'B' key) to find
>> it in order to hear the extra instructions.
>> Or you could use the aria-disabled attribute (instead of the disabled
>> attribute) so that keyboard focus could still go to the button but
>> you'd need javascript to prevent any actions on the button, which I'm
>> guessing your legal dept would not like.
>>
>> Just tossing ideas out there.
>>
>> Glen
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > http://webaim.org/discussion/archives
> > > > > >