WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WebAIM-Forum Digest, Vol 190, Issue 4

for

From: Brooks Newton
Date: Jan 4, 2021 2:50PM

Hi,

I still stand by my statement about non-interactive elements in the focus
order. In my book, that's a WCAG fail. Last time I checked, "failing" a
page component in a WCAG review isn't synonymous with prioritizing errors
for clients. In other words, it's not OK to say that page conforms to WCAG
just because you personally don't think that errors you've found aren't
important. That's not how the WCAG conformance model works. I've been
part of the Accessibility Guidelines Working Group for the last four
years. And I can tell you that each and every A and AA Success Criterion
included in the WCAG standard is a big deal to someone, in terms of being a
potential deal-breaker. Removing non-interactive tab stops from the focus
order of the page is an easy fix to make, and that fix alleviates all sorts
of confusion about the role of non-interactive elements to keyboard users.
It also removes unnecessary blocks in the way of keyboard users advancing
to the content they want in the page content order.

I know it is hard to imagine for some, but not everyone is going to "get
it," in terms of being able to go ahead and operate an interface that is
scattered with non-interactive elements in the tab order of the page. For
some, this is a deal breaker. I also don't buy for one second that
establishing and meeting user expectations don't matter when it comes to
designing implementing web page content. Of course they matter.
Guidelines 3.2 (Predictable) and 3.3 (Input Assistance) are all about
managing user expectations. I don't need anyone on this thread to validate
my ticket as an expert in this field. Resorting to name calling in an
attempt to dissuade honest discourse about accessibility issues is what
bullies do. Not everyone agrees with how WCAG applies to various content
constructs. We don't all move in lock step. If we did, I think it would
look a bit fishy. There are many subjective points in this line of work.
Don't ever let anyone tell you differently. It's OK to disagree - just
make your argument using data, not resorting to childish ad hominem attacks.

Brooks

On Mon, Jan 4, 2021 at 1:03 PM < <EMAIL REMOVED> > wrote:

> Send WebAIM-Forum mailing list submissions to
> <EMAIL REMOVED>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.webaim.org/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> <EMAIL REMOVED>
>
> You can reach the person managing the list at
> <EMAIL REMOVED>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Mallory)
> 2. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Steve Green)
> 3. Code fix for every cell in a table being focusable (Mark Magennis)
> 4. Re: Code fix for every cell in a table being focusable
> ( <EMAIL REMOVED> )
> 5. Re: Code fix for every cell in a table being focusable
> (Swift, Daniel P.)
> 6. Accessible Carousel Working (Radhika Soni)
> 7. Re: Accessible Carousel Working (Jerra Strong)
>
>
>
> ---------- Forwarded message ----------
> From: Mallory < <EMAIL REMOVED> >
> To: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >, WebAIM
> Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Mon, 04 Jan 2021 09:40:05 +0100
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable
> in tables
> Steve,
> >In what possible way is it hurtful to achieve AA conformance?
>
> Birkir answered what I would have said: the example WCAG compliant page
> with the billion Tab stops is harmful to real people, but passes WCAG. If a
> client hired me to say that I'd go find them someone with less soul left
> over to do it instead. There's a place for lawyers who can get their
> clients off serious charges based on technicalities (the system of the law
> has to work), but I'd rather not be the one to do it.
>
> You may be thinking of clients who are so awful qua accessibility that
> even a WCAG audit improves them. This can be true. However many of these
> are the clients who argue on every point to claim why they don't have to,
> or make "fixes" that are awful but are now improved enough that you can't
> in good conscious fail them on that SC anymore (let's say, going from zero
> keyboard accessibility, a clear fail, to a dynamically-added tabindex=0 to
> every element, even though that's not what you recommended). They are also
> the repeat customers, coming back every 6 months or year to have another
> audit, only to show that they not only invented their own changes but have
> nothing systemic to keep fixes viable and they get poor scores every time.
> Sometimes it seems the legal requirement is simply "we recently had a WCAG
> AA audit" rather than actually fix anything. I only have so many years to
> live, yo, and I'd like to keep my remaining hairs on my head.
>
> After a lot of thinking, I think I know what this is. Someone I know (a
> developer) has been running into this at his work as well. A company says
> "we want to be accessible!" or "accessibility is important to us!" but it
> turns out what that means is the same thing as "we care about children
> starving in Africa! We believe that's horrible!" I think a lot of
> developers have this too. They want, in a generalised foggy way, to be what
> they consider or were told to be good, but they don't know what that means
> in a practical manner.
> Once they see it, the specific things they need to do, the ideal starts
> having a cost. This quickly turns into a "let's see what's literally,
> minimally required by us" check. So where my developer friend worked, it
> turned out that the company went and checked how compliant they needed to
> be and discovered that their company is *explicitly named in the nation's
> accessibility law* as being exempted (even though they receive government
> funding). Once they discovered that, it was back to "accessibility is
> important, but our pasty branding colours on links is even more important."
> And so this is the state of that software today (in 2025 the law will
> adjust and they'll also have to comply, but I see them doing it like a cat
> struggling to not get dunked into a bathtub).
>
> And yes, I know people out there advertising services who would know they
> could pass a billion-Tab-stop page ("it's keyboard accessible, after
> all!"). They recommend setting overly-verbose aria-labels on everything and
> don't know best practice techniques, but none of those things fail WCAG.
> They're (probably) cheaper than I am. Better for the law-abiding client;
> now they're paying less.
>
> (Where are these people? I tend to find them because they message me on
> LinkedIn/email offering their services, lol. I'm not saying they're amazing
> and agree some are insufficient, but I mean, WCAG is a basement-bare
> minimum, not rocket surgery.)
>
> cheers,
> _mallory
>
> On Sun, Jan 3, 2021, at 3:04 AM, Birkir R. Gunnarsson wrote:
> > I totally agree that audit context is important. My initial reply to
> > this list highlighting that sometimes I can fail things for my company
> > without mapping it to a specific WCAG success criterion speaks to my
> > employer's commitment to an accessible and usable experience, so it
> > was just a note of appreciation for that. I spent years as a
> > consultant strictly auditing to WCAG, and part of the reason I
> > switched jobs was the opportunity to stop so heavily focusing on WCAG
> > and starting to focus on accessibility/ax (accessible experience).
> > WCAG 2.1 AA is still the standard, but if I come across serious AX
> > problems I can record and assign severity based on our assessment of
> > the user impact.
> >
> > I still have to say that if you can make tens or hundreds of static
> > webpage elements keyboard focusable without failing a WCAG success
> > criterion, then WCAG is broken in that regard and this is something
> > that needs to be fixed. I may have to look at filing an issue against
> > WCAG 3.0 to have this looked into.
> >
> >
> > I would still fail this under either success criterion 2.1.2.,
> > keyboard trap (if it's near impossible to get past the static elements
> > in the table with the tab key this constitutes a keyboard trap) or
> > 2.4.3 (I don't see how sending focus to dozens of non-focusable and
> > non-operable elements preserves meaning and operation, especially
> > operation).
> > Again, it's all about context, if the table has a "skip past table"
> > link this wouldn't apply. If the table is only in one location and
> > there's nothing operable after it (safe, perhaps the footer), it
> > probably would not be more than a minor to moderate impact. It also
> > depends on the number of static focusable elements, is it 1, 10, 100,
> > or hundreds?
> > Also it depends if the page is a static/public page or whether it is
> > located behind a session where you can literally time out while
> > tabbing through the static elements, in that case the keyboard trap
> > argument becomes pretty strong.
> > So, context, context, context. Accessibility would not be a legitimate
> > and respected industry without a standard, and WCAG has done miracles,
> > but it's technology agnostic nature that makes it so powerful and
> > flexible can sometimes present confusion and inconsistencies between
> > experts, because interpretation is required.
> > And that, folks, is why this WebAIM mailing list is so great. I love
> > reading all the points of view and I never stop learning. I may
> > occasionally disagree with some posts but I never fail to appreciate
> > the thoughts and I have often changed my mind after reading all the
> > awesome discussions on here.
> > Cheers
> >
> >
> >
> > On 1/2/21, Steve Green < <EMAIL REMOVED> > wrote:
> > > " Yet another reason to avoid performing "WCAG audits". I believe
> they're
> > > hurtful, and clients who want to only stick to it are cheaper served
> by any
> > > fly-by-night "a11y experts"."
> > >
> > > I don't often disagree with you, but that's absolute nonsense. The
> reality
> > > is that the vast majority of organisations are only interested in legal
> > > compliance. That can mean different things in different countries. For
> US
> > > organisations that are covered by Section 508, it means conformance
> with
> > > WCAG 2.0 rather than 2.1. In the UK, all public sector organisations
> must
> > > meet WCAG 2.1, but there are exceptions for certain types of content.
> > >
> > > In what possible way is it hurtful to achieve AA conformance? If you're
> > > suggesting that level AA isn't enough, then where do you draw the line
> and
> > > why? It's always possible to do more, so any line is arbitrary and
> it's a
> > > matter of diminishing returns after that.
> > >
> > > And the idea that there are "fly-by-night a11y experts" who can
> competently
> > > test for WCAG conformance is wishful thinking. In the UK there are
> probably
> > > no more than 10 testing companies and a handful of freelancers who can
> > > conduct a WCAG audit competently. It's really, really difficult and
> takes
> > > many thousands of hours of study and experience. Most of the test
> reports I
> > > have seen from other organisations and freelancers are very poor. Of
> course
> > > there are some notable exceptions in this forum.
> > >
> > > Steve
> > >
> > >
> > > -----Original Message-----
> > > From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> > > Mallory
> > > Sent: 02 January 2021 13:21
> > > To: WebAIM Discussion List < <EMAIL REMOVED> >
> > > Subject: Re: [WebAIM] WCAG - Fail or not to - Static text
> tab-focusable in
> > > tables
> > >
> > > I suppose technically a button which can only be activated with the
> "r" key
> > > also passes 2.1.1.
> > >
> > > Yet another reason to avoid performing "WCAG audits". I believe they're
> > > hurtful, and clients who want to only stick to it are cheaper served
> by any
> > > fly-by-night "a11y experts".
> > >
> > > However reports should always put the "this is 110% unusable" issues
> under a
> > > "UX" heading or something, and not point to an SC.
> > >
> > > cheers,
> > > _mallory
> >
>
>
>
>
> ---------- Forwarded message ----------
> From: Steve Green < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >, "Birkir R.
> Gunnarsson" < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Mon, 4 Jan 2021 09:15:00 +0000
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable in
> tables
> Mallory, it sounds like your experience of the accessibility market is
> entirely different from mine. Your statement "clients who are so awful qua
> accessibility that even a WCAG audit improves them" applies to every client
> we have ever had.
>
> We have worked for many hundreds of clients and not one of them was
> anywhere near WCAG AA conformant when they first came to us. In most cases,
> merely achieving AA conformance was extraordinarily difficult and very few
> actually got there even after many rounds of fixing and retesting - there
> are almost always some things that can't be fixed.
>
> If your clients are organisations who already exceed AA and want to get
> even better, then I would love to know where you find them. In nearly 20
> years, I have never encountered a client like that.
>
> I would also add a qualifier to your final statement. Developing a WCAG
> AA-conformant website is not rocket surgery if you know what you are doing.
> However, competently testing an existing badly designed website and making
> the necessary recommendations for changes *is* rocket surgery. Anyone can
> do it badly, but it's insanely difficult to do well, given the appalling
> state of most of the websites we are asked to work on. The really scary
> thing is that despite being appalling, most of them are better than those
> that are doing nothing about accessibility.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Mallory
> Sent: 04 January 2021 08:40
> To: Birkir R. Gunnarsson < <EMAIL REMOVED> >; WebAIM Discussion
> List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable in
> tables
>
> Steve,
> >In what possible way is it hurtful to achieve AA conformance?
>
> Birkir answered what I would have said: the example WCAG compliant page
> with the billion Tab stops is harmful to real people, but passes WCAG. If a
> client hired me to say that I'd go find them someone with less soul left
> over to do it instead. There's a place for lawyers who can get their
> clients off serious charges based on technicalities (the system of the law
> has to work), but I'd rather not be the one to do it.
>
> You may be thinking of clients who are so awful qua accessibility that
> even a WCAG audit improves them. This can be true. However many of these
> are the clients who argue on every point to claim why they don't have to,
> or make "fixes" that are awful but are now improved enough that you can't
> in good conscious fail them on that SC anymore (let's say, going from zero
> keyboard accessibility, a clear fail, to a dynamically-added tabindex=0 to
> every element, even though that's not what you recommended). They are also
> the repeat customers, coming back every 6 months or year to have another
> audit, only to show that they not only invented their own changes but have
> nothing systemic to keep fixes viable and they get poor scores every time.
> Sometimes it seems the legal requirement is simply "we recently had a WCAG
> AA audit" rather than actually fix anything. I only have so many years to
> live, yo, and I'd like to keep my remaining hairs on my head.
>
> After a lot of thinking, I think I know what this is. Someone I know (a
> developer) has been running into this at his work as well. A company says
> "we want to be accessible!" or "accessibility is important to us!" but it
> turns out what that means is the same thing as "we care about children
> starving in Africa! We believe that's horrible!" I think a lot of
> developers have this too. They want, in a generalised foggy way, to be what
> they consider or were told to be good, but they don't know what that means
> in a practical manner.
> Once they see it, the specific things they need to do, the ideal starts
> having a cost. This quickly turns into a "let's see what's literally,
> minimally required by us" check. So where my developer friend worked, it
> turned out that the company went and checked how compliant they needed to
> be and discovered that their company is *explicitly named in the nation's
> accessibility law* as being exempted (even though they receive government
> funding). Once they discovered that, it was back to "accessibility is
> important, but our pasty branding colours on links is even more important."
> And so this is the state of that software today (in 2025 the law will
> adjust and they'll also have to comply, but I see them doing it like a cat
> struggling to not get dunked into a bathtub).
>
> And yes, I know people out there advertising services who would know they
> could pass a billion-Tab-stop page ("it's keyboard accessible, after
> all!"). They recommend setting overly-verbose aria-labels on everything and
> don't know best practice techniques, but none of those things fail WCAG.
> They're (probably) cheaper than I am. Better for the law-abiding client;
> now they're paying less.
>
> (Where are these people? I tend to find them because they message me on
> LinkedIn/email offering their services, lol. I'm not saying they're amazing
> and agree some are insufficient, but I mean, WCAG is a basement-bare
> minimum, not rocket surgery.)
>
> cheers,
> _mallory
>
> On Sun, Jan 3, 2021, at 3:04 AM, Birkir R. Gunnarsson wrote:
> > I totally agree that audit context is important. My initial reply to
> > this list highlighting that sometimes I can fail things for my company
> > without mapping it to a specific WCAG success criterion speaks to my
> > employer's commitment to an accessible and usable experience, so it
> > was just a note of appreciation for that. I spent years as a
> > consultant strictly auditing to WCAG, and part of the reason I
> > switched jobs was the opportunity to stop so heavily focusing on WCAG
> > and starting to focus on accessibility/ax (accessible experience).
> > WCAG 2.1 AA is still the standard, but if I come across serious AX
> > problems I can record and assign severity based on our assessment of
> > the user impact.
> >
> > I still have to say that if you can make tens or hundreds of static
> > webpage elements keyboard focusable without failing a WCAG success
> > criterion, then WCAG is broken in that regard and this is something
> > that needs to be fixed. I may have to look at filing an issue against
> > WCAG 3.0 to have this looked into.
> >
> >
> > I would still fail this under either success criterion 2.1.2.,
> > keyboard trap (if it's near impossible to get past the static elements
> > in the table with the tab key this constitutes a keyboard trap) or
> > 2.4.3 (I don't see how sending focus to dozens of non-focusable and
> > non-operable elements preserves meaning and operation, especially
> > operation).
> > Again, it's all about context, if the table has a "skip past table"
> > link this wouldn't apply. If the table is only in one location and
> > there's nothing operable after it (safe, perhaps the footer), it
> > probably would not be more than a minor to moderate impact. It also
> > depends on the number of static focusable elements, is it 1, 10, 100,
> > or hundreds?
> > Also it depends if the page is a static/public page or whether it is
> > located behind a session where you can literally time out while
> > tabbing through the static elements, in that case the keyboard trap
> > argument becomes pretty strong.
> > So, context, context, context. Accessibility would not be a legitimate
> > and respected industry without a standard, and WCAG has done miracles,
> > but it's technology agnostic nature that makes it so powerful and
> > flexible can sometimes present confusion and inconsistencies between
> > experts, because interpretation is required.
> > And that, folks, is why this WebAIM mailing list is so great. I love
> > reading all the points of view and I never stop learning. I may
> > occasionally disagree with some posts but I never fail to appreciate
> > the thoughts and I have often changed my mind after reading all the
> > awesome discussions on here.
> > Cheers
> >
> >
> >
> > On 1/2/21, Steve Green < <EMAIL REMOVED> > wrote:
> > > " Yet another reason to avoid performing "WCAG audits". I believe
> > > they're hurtful, and clients who want to only stick to it are
> > > cheaper served by any fly-by-night "a11y experts"."
> > >
> > > I don't often disagree with you, but that's absolute nonsense. The
> > > reality is that the vast majority of organisations are only
> > > interested in legal compliance. That can mean different things in
> > > different countries. For US organisations that are covered by
> > > Section 508, it means conformance with WCAG 2.0 rather than 2.1. In
> > > the UK, all public sector organisations must meet WCAG 2.1, but there
> are exceptions for certain types of content.
> > >
> > > In what possible way is it hurtful to achieve AA conformance? If
> > > you're suggesting that level AA isn't enough, then where do you draw
> > > the line and why? It's always possible to do more, so any line is
> > > arbitrary and it's a matter of diminishing returns after that.
> > >
> > > And the idea that there are "fly-by-night a11y experts" who can
> > > competently test for WCAG conformance is wishful thinking. In the UK
> > > there are probably no more than 10 testing companies and a handful
> > > of freelancers who can conduct a WCAG audit competently. It's
> > > really, really difficult and takes many thousands of hours of study
> > > and experience. Most of the test reports I have seen from other
> > > organisations and freelancers are very poor. Of course there are some
> notable exceptions in this forum.
> > >
> > > Steve
> > >
> > >
> > > -----Original Message-----
> > > From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf
> > > Of Mallory
> > > Sent: 02 January 2021 13:21
> > > To: WebAIM Discussion List < <EMAIL REMOVED> >
> > > Subject: Re: [WebAIM] WCAG - Fail or not to - Static text
> > > tab-focusable in tables
> > >
> > > I suppose technically a button which can only be activated with the
> > > "r" key also passes 2.1.1.
> > >
> > > Yet another reason to avoid performing "WCAG audits". I believe
> > > they're hurtful, and clients who want to only stick to it are
> > > cheaper served by any fly-by-night "a11y experts".
> > >
> > > However reports should always put the "this is 110% unusable" issues
> > > under a "UX" heading or something, and not point to an SC.
> > >
> > > cheers,
> > > _mallory
> >
> > > at http://webaim.org/discussion/archives
> >
>
>
>
> ---------- Forwarded message ----------
> From: Mark Magennis < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Mon, 4 Jan 2021 16:24:14 +0000
> Subject: [WebAIM] Code fix for every cell in a table being focusable
> The recent discussion about every cell in a table being tab-focusable has
> prompted me to wonder about what's the best fix. That discussion was about
> an ng-grid table but I've also seen it with tables generated using ext.js
> where each cell has tabindex="0".
>
> I'm not a JavaScript whizz by any means but presumably it's just a simple
> case of running a script after the page has loaded (and also after a new
> row has been added if the table allows that) to strip out the tabindexes.
> Has anyone done that and is it really that simple? Are there any
> difficulties, such as finding out the cell's id's? Or is there a better
> approach that I can recommend if I come across this in future?
>
> Thanks,
> Mark
>
>
>
>
> ---------- Forwarded message ----------
> From: <EMAIL REMOVED>
> To: <EMAIL REMOVED>
> Cc:
> Bcc:
> Date: Tue, 05 Jan 2021 00:24:36 +0800
> Subject: Re: [WebAIM] Code fix for every cell in a table being focusable
> 您好！我是江苏君华特种工程塑料制品有限公司的总经理李军，我的手机号码为13382868677，感谢您发来的邮件！我会尽快处理答复您！
> Hello，I am Jolly Li， the general manager of Jiangsu Junhua High
> Performance Engineering Plastic Products Co.，Ltd. Thanks for your mail ，it
> is well received，I will get back to you as soon as possible.
>
>
> ---------- Forwarded message ----------
> From: "Swift, Daniel P." < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Mon, 4 Jan 2021 17:38:33 +0000
> Subject: Re: [WebAIM] Code fix for every cell in a table being focusable
> Mark:
>
> I haven't done what you are specifically describing, but I've done similar
> things in certain situations where I didn't have access to the code which
> we needed to change. It's about as simple as you describe ... wait for the
> page to load, find everything within a container that has a certain
> attribute, and remove that attribute. You should be able to achieve that
> with a few lines of code.
>
> Daniel Swift, MBA
> Senior Web Specialist
> University Communications and Marketing
> West Chester University
> 610.738.0589
>
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Mark Magennis
> Sent: Monday, January 4, 2021 11:24 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: [WebAIM] Code fix for every cell in a table being focusable
>
> The recent discussion about every cell in a table being tab-focusable has
> prompted me to wonder about what's the best fix. That discussion was about
> an ng-grid table but I've also seen it with tables generated using ext.js
> where each cell has tabindex="0".
>
> I'm not a JavaScript whizz by any means but presumably it's just a simple
> case of running a script after the page has loaded (and also after a new
> row has been added if the table allows that) to strip out the tabindexes.
> Has anyone done that and is it really that simple? Are there any
> difficulties, such as finding out the cell's id's? Or is there a better
> approach that I can recommend if I come across this in future?
>
> Thanks,
> Mark
> > > http://list.webaim.org>;
> > http://webaim.org/discussion/archives>;
> > <EMAIL REMOVED> >
>
>
>
>
> ---------- Forwarded message ----------
> From: Radhika Soni < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Mon, 4 Jan 2021 13:03:51 -0500
> Subject: [WebAIM] Accessible Carousel Working
> I need some help with what is the ideal/ accessible behaviour for a
> carousel. As soon as the user hit the next button, should the focus go to
> the slide or should the focus stay on the next button itself.
> How will users be intimated about the next slide content? Any examples
> which you can share for the best examples for carousels?
>
> Thanks in advance for your help!
>
>
> Regards,
> -Radhika
>
>
>
>
> ---------- Forwarded message ----------
> From: Jerra Strong < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Mon, 4 Jan 2021 10:49:27 -0800
> Subject: Re: [WebAIM] Accessible Carousel Working
> Hi Radhika,
>
> W3C has an Accessible Carousel Tutorial
> <https://www.w3.org/WAI/tutorials/carousels/> available that goes into the
> accessibility concepts, with code examples. Hope this is helpful to you.
>
> On Mon, Jan 4, 2021 at 10:04 AM Radhika Soni < <EMAIL REMOVED> >
> wrote:
>
> > I need some help with what is the ideal/ accessible behaviour for a
> > carousel. As soon as the user hit the next button, should the focus go to
> > the slide or should the focus stay on the next button itself.
> > How will users be intimated about the next slide content? Any examples
> > which you can share for the best examples for carousels?
> >
> > Thanks in advance for your help!
> >
> >
> > Regards,
> > -Radhika
> > > > > > > > > >
>
>
> --
> Jerra Strong
> Interim Accessible Conformance and Design Specialist
> UNLV|Office of Accessibility Resources
> Office of the Vice Provost for Academic Programs
> <EMAIL REMOVED>
> *Pronouns: He/Him/His*
>
> > > > >