WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Scrolling Agree to Terms Screen

for

From: Swift, Daniel P.
Date: Sep 21, 2018 5:34AM

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
> >