WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: John Foliot
Date: Jan 4, 2021 4:22PM

Edit:

...not really a candidate for for *aria-labeledby*...

JF

On Mon, Jan 4, 2021 at 6:20 PM John Foliot < <EMAIL REMOVED> > wrote:

> Brooks writes:
>
> > I still stand by my statement about non-interactive elements in the
> focus order. In my book, that's a WCAG fail.
>
> Hi Brooks,
>
> I am going to respectfully disagree, at least slightly.
>
> There are indeed use-cases and scenarios where placing non-interactive
> content in the tab order is actually important, and in fact may be
> necessary; the most common one being important text (<p>) embedded part way
> in a form - text that is related to a part of the form, but not
> specifically to an input (so thus, not really a candidate for aria-label or
> aria-describedby). For non-sighted users, with their screen readers in
> "Forms Mode", they might miss that important text as they tab from one
> input to the next (expected behavior), because the reading experience in
> Forms mode is different. Because of that difference, I'd in fact invoke *Success
> Criterion 1.3.2 Meaningful Sequence*, which states:
>
> "*When the sequence in which content is presented affects its meaning* (i.e.
> the important text needs to be read aloud in the middle of, and in the
> context of, the larger form)*, a correct reading sequence can be
> programmatically determined.*"
>
>
> So personally, I would avoid broad statements like that as being, if
> nothing else, a wee bit too simplistic.
>
> I do agree however that we're also seeing a trend where some developers
> "over-react" and try to make everything (or specific elements, such as
> Headings) tab-focusable, at which point they are introducing searious
> usability concerns (although, I am curious, if you consider it a WCAG Fail,
> which SC is it failing?). In those cases, I do agree that it's not helpful,
> and in fact can be harmful [sic] for some users.
>
> Respectfully,
>
> JF
>
> On Mon, Jan 4, 2021 at 4:51 PM Brooks Newton < <EMAIL REMOVED> >
> wrote:
>
>> 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
>> > >
>> > >> > >> archives
>> > 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*
>> >
>> > >> > >> > >> > >> >
>> >> >> >> >>
>

--
*​John Foliot* | Principal Accessibility Specialist
Deque Systems - Accessibility for Good
deque.com
"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"