E-mail List Archives
Thread: Scrolling Agree to Terms Screen
Number of posts in this thread: 9 (In chronological order)
From: Isabel Holdsworth
Date: Thu, Sep 20 2018 5:48AM
Subject: Scrolling Agree to Terms Screen
No previous message | Next message →
Hi all,
We have an "Agree to terms" screen, where the "I agree" button is
disabled until users have scrolled to the end of the terms and
conditions. This scenario is non-negotiable for legal reasons.
One of my colleagues created a prototype that has the T&Cs in a
scrollable div with tabindex="0". It works great using a keyboard, but
screenreaders don't know what the component is or how to interact with
it.
I made it work quite well by adding contentEditable="true" to the div.
But, again for legal reasons, this approach won't get past our change
board even if we use JavaScript to disable editing.
Have any of you created an accessible component that has this
functionality? If so, how did you do it? And if not, do you have any
thoughts on how to go about it?
As always, thanks for any advice or ideas.
Cheers, Isabel
From: Patrick H. Lauke
Date: Thu, Sep 20 2018 6:03AM
Subject: Re: Scrolling Agree to Terms Screen
← Previous message | Next message →
i'd hazard a guess that it's not legally enforceable / has no actual legal weight either way. it's the legal department not understanding technology...
i'd make the div scroll automagically on focus of the agree button and being done with it, after explaining to them that AT users can read the entire thing without scrolling and there's no way to detect it. and it has the same legal weight (not much) as those "i have read and agree to the Ts&Cs" checkboxes.
p
> On 20 Sep 2018, at 14:48, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi all,
>
> We have an "Agree to terms" screen, where the "I agree" button is
> disabled until users have scrolled to the end of the terms and
> conditions. This scenario is non-negotiable for legal reasons.
>
> One of my colleagues created a prototype that has the T&Cs in a
> scrollable div with tabindex="0". It works great using a keyboard, but
> screenreaders don't know what the component is or how to interact with
> it.
>
> I made it work quite well by adding contentEditable="true" to the div.
> But, again for legal reasons, this approach won't get past our change
> board even if we use JavaScript to disable editing.
>
> Have any of you created an accessible component that has this
> functionality? If so, how did you do it? And if not, do you have any
> thoughts on how to go about it?
>
> As always, thanks for any advice or ideas.
>
> Cheers, Isabel
> > > >
From: Isabel Holdsworth
Date: Thu, Sep 20 2018 6:52AM
Subject: Re: Scrolling Agree to Terms Screen
← Previous message | Next message →
Thanks Patrick. That's how it used to work, but we've been told to
change it so that's what we need to do.
I just need to find an accessible way to accomplish it.
Cheers, Isabel
On 20/09/2018, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> i'd hazard a guess that it's not legally enforceable / has no actual legal
> weight either way. it's the legal department not understanding technology...
>
> i'd make the div scroll automagically on focus of the agree button and being
> done with it, after explaining to them that AT users can read the entire
> thing without scrolling and there's no way to detect it. and it has the same
> legal weight (not much) as those "i have read and agree to the Ts&Cs"
> checkboxes.
>
> p
>
>> On 20 Sep 2018, at 14:48, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> Hi all,
>>
>> We have an "Agree to terms" screen, where the "I agree" button is
>> disabled until users have scrolled to the end of the terms and
>> conditions. This scenario is non-negotiable for legal reasons.
>>
>> One of my colleagues created a prototype that has the T&Cs in a
>> scrollable div with tabindex="0". It works great using a keyboard, but
>> screenreaders don't know what the component is or how to interact with
>> it.
>>
>> I made it work quite well by adding contentEditable="true" to the div.
>> But, again for legal reasons, this approach won't get past our change
>> board even if we use JavaScript to disable editing.
>>
>> Have any of you created an accessible component that has this
>> functionality? If so, how did you do it? And if not, do you have any
>> thoughts on how to go about it?
>>
>> As always, thanks for any advice or ideas.
>>
>> Cheers, Isabel
>> >> >> >> >
> > > > >
From: glen walker
Date: Thu, Sep 20 2018 11:15AM
Subject: Re: Scrolling Agree to Terms Screen
← Previous message | Next message →
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
From: Isabel Holdsworth
Date: Fri, Sep 21 2018 3:13AM
Subject: Re: Scrolling Agree to Terms Screen
← Previous message | Next message →
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 ADDRESS 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
> > > > >
From: Swift, Daniel P.
Date: Fri, Sep 21 2018 5:34AM
Subject: Re: Scrolling Agree to Terms Screen
← Previous message | Next message →
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 ADDRESS REMOVED = ] On Behalf Of Isabel Holdsworth
Sent: Friday, September 21, 2018 5:14 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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
> >
From: Isabel Holdsworth
Date: Fri, Sep 21 2018 7:03AM
Subject: Re: Scrolling Agree to Terms Screen
← Previous message | Next message →
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 ADDRESS 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 ADDRESS REMOVED = ] On Behalf
> Of Isabel Holdsworth
> Sent: Friday, September 21, 2018 5:14 AM
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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
> > > > > >
From: glen walker
Date: Fri, Sep 21 2018 8:47AM
Subject: Re: Scrolling Agree to Terms Screen
← Previous message | Next message →
Does the user (sighted or not) have to *scroll* through the terms or will
the END key be sufficient?
On Fri, Sep 21, 2018 at 7:03 AM Isabel Holdsworth < = EMAIL ADDRESS REMOVED = >
wrote:
> It would probably work, but one client insists on everyone scrolling
> through the entire agreement.
>
>
>
From: Isabel Holdsworth
Date: Mon, Sep 24 2018 4:47AM
Subject: Re: Scrolling Agree to Terms Screen
← Previous message | No next message
They can PGDN through the agreement, but END doesn't work. I think the
tabbed agreement is the closest compromise we can come to.
On 21/09/2018, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Does the user (sighted or not) have to *scroll* through the terms or will
> the END key be sufficient?
>
> On Fri, Sep 21, 2018 at 7:03 AM Isabel Holdsworth
> < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> It would probably work, but one client insists on everyone scrolling
>> through the entire agreement.
>>
>>
>>
> > > > >