WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Tab navigation for non-interactive content?

for

Number of posts in this thread: 13 (In chronological order)

From: Erik Conrad
Date: Thu, Oct 27 2016 1:04PM
Subject: Tab navigation for non-interactive content?
No previous message | Next message →

Hello everyone,



I am relatively new to designing for accessibility, and while I have been
reading and researching as much as I can, I have some questions about the
specifics of my design problem where any advice from those with more
experience (as users, designers, or developers) would be greatly
appreciated.



I am working on user interfaces for online tests that are rendered in HTML
like a web page, but otherwise work more like an application. I have
noticed that many web applications have extensive lists of hotkeys (like
gmail, twitter, etc.) to facilitate keyboard navigation and get around
their UIs. In my case, I do not believe that this is useful, as most users
will only ever take a test once, so learning a bunch of custom key combos
has limited use.



Depending on the test, there are a few major sections of the UI that serve
different purposes: timing, various kinds of information, navigation, the
question(s), etc. I think (possibly incorrectly) that adding the major
sections of the UI to the tabindex makes it easy to get around the UI with
the keyboard, while only adding a few extra tab stops. (Also, many of the
UI sections are in separate frames - old school frames, not iframes - which
I know can cause problems with screen readers and such, but there is
nothing that I can do about that).



I know that having a tabindex on non-interactive content is not a best
practice and may be unexpected or annoying for users who normally use the
keyboard to navigate, but as someone with experience in UI design but new
to accessibility, it seems like a fair trade off. I would greatly
appreciate any opinions about how wrong (or right?) I am about that.



Thank you for reading my long post, I would greatly appreciate any feedback.


-Erik

--
erik conrad
http://www.peripheralfocus.net
email: = EMAIL ADDRESS REMOVED = or = EMAIL ADDRESS REMOVED =

From: Birkir R. Gunnarsson
Date: Thu, Oct 27 2016 1:21PM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

Eric
I can totlly see your dilemma there.
Making non-interactive focusable adds keystrokes for the keyboard only
user and can potentially confuse screen reader users navigateing the
page with the tab key. (screen readers are not user what text to read
when an element without a role gets focus).
So generally speaking this is not a good idea, but we are not
generally speaking. ;)
Have you considered using something like the PayPal skip to widget:
https://github.com/paypal/skipto
If you us that, together with marking important section headingsup
correctly, you may be on to a winner (headings work for the screen
reader user and provide targets for the skip link for keyboard only
users).
The keyboard only user can always get to the top of the page
(ctrl-home) and tab to into the widget, then select the heading and
go, so.
So you achieve keyboard navigability without cluttering up the focus
order and confuse the heck out of the screen reader.
Of course there could be technical reasons why this solution doesn't
work, but it sounds like a promising first attempt.
-B


On 10/27/16, Erik Conrad < = EMAIL ADDRESS REMOVED = > wrote:
> Hello everyone,
>
>
>
> I am relatively new to designing for accessibility, and while I have been
> reading and researching as much as I can, I have some questions about the
> specifics of my design problem where any advice from those with more
> experience (as users, designers, or developers) would be greatly
> appreciated.
>
>
>
> I am working on user interfaces for online tests that are rendered in HTML
> like a web page, but otherwise work more like an application. I have
> noticed that many web applications have extensive lists of hotkeys (like
> gmail, twitter, etc.) to facilitate keyboard navigation and get around
> their UIs. In my case, I do not believe that this is useful, as most users
> will only ever take a test once, so learning a bunch of custom key combos
> has limited use.
>
>
>
> Depending on the test, there are a few major sections of the UI that serve
> different purposes: timing, various kinds of information, navigation, the
> question(s), etc. I think (possibly incorrectly) that adding the major
> sections of the UI to the tabindex makes it easy to get around the UI with
> the keyboard, while only adding a few extra tab stops. (Also, many of the
> UI sections are in separate frames - old school frames, not iframes - which
> I know can cause problems with screen readers and such, but there is
> nothing that I can do about that).
>
>
>
> I know that having a tabindex on non-interactive content is not a best
> practice and may be unexpected or annoying for users who normally use the
> keyboard to navigate, but as someone with experience in UI design but new
> to accessibility, it seems like a fair trade off. I would greatly
> appreciate any opinions about how wrong (or right?) I am about that.
>
>
>
> Thank you for reading my long post, I would greatly appreciate any feedback.
>
>
> -Erik
>
> --
> erik conrad
> http://www.peripheralfocus.net
> email: = EMAIL ADDRESS REMOVED = or = EMAIL ADDRESS REMOVED =
> > > > >


--
Work hard. Have fun. Make history.

From: Andrews, David B (DEED)
Date: Thu, Oct 27 2016 1:40PM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

You are right ... for a one-time application, lists of hot keys probably aren't worth it. Further, there are no standards for hot keys, so conflicts can happen, and unless you use something a lot, you just don't remember.

At one time frames were a problem, for screen readers, but any modern screen reader should be able to handle them. As a design mechanism, they have gone out of favor, but personally I like them for some applications. My grocery shopping site, local, used to use them, with your shopping list in a frame, and other sections in their own frames. It worked great, but of course they took them away and didn't put anything in their place. Headings is probably the best, and easiest way to navigate larger sections, you could have each section of the test as a H2 and individual pieces under each as H3's.

Dave



David Andrews | Chief Technology Officer
Department of Employment and Economic Development
State Services for the Blind, 2200 University Ave. W., Suite 240, St. Paul MN 55114
Direct: 651-539-2294 | Mobile: 612-730-7931
Web | Twitter | Facebook



-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Erik Conrad
Sent: Thursday, October 27, 2016 2:05 PM
To: = EMAIL ADDRESS REMOVED =
Subject: [WebAIM] Tab navigation for non-interactive content?

Hello everyone,



I am relatively new to designing for accessibility, and while I have been reading and researching as much as I can, I have some questions about the specifics of my design problem where any advice from those with more experience (as users, designers, or developers) would be greatly appreciated.



I am working on user interfaces for online tests that are rendered in HTML like a web page, but otherwise work more like an application. I have noticed that many web applications have extensive lists of hotkeys (like gmail, twitter, etc.) to facilitate keyboard navigation and get around their UIs. In my case, I do not believe that this is useful, as most users will only ever take a test once, so learning a bunch of custom key combos has limited use.



Depending on the test, there are a few major sections of the UI that serve different purposes: timing, various kinds of information, navigation, the question(s), etc. I think (possibly incorrectly) that adding the major sections of the UI to the tabindex makes it easy to get around the UI with the keyboard, while only adding a few extra tab stops. (Also, many of the UI sections are in separate frames - old school frames, not iframes - which I know can cause problems with screen readers and such, but there is nothing that I can do about that).



I know that having a tabindex on non-interactive content is not a best practice and may be unexpected or annoying for users who normally use the keyboard to navigate, but as someone with experience in UI design but new to accessibility, it seems like a fair trade off. I would greatly appreciate any opinions about how wrong (or right?) I am about that.



Thank you for reading my long post, I would greatly appreciate any feedback.


-Erik

--
erik conrad
http://www.peripheralfocus.net
email: = EMAIL ADDRESS REMOVED = or = EMAIL ADDRESS REMOVED =

From: Patrick H. Lauke
Date: Thu, Oct 27 2016 4:03PM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

On 27/10/2016 20:04, Erik Conrad wrote:

> I know that having a tabindex on non-interactive content is not a best
> practice and may be unexpected or annoying for users who normally use the
> keyboard to navigate, but as someone with experience in UI design but new
> to accessibility, it seems like a fair trade off. I would greatly
> appreciate any opinions about how wrong (or right?) I am about that.

Coincidentally, I've just recently pushed a change to the W3C HTML5.2
editor's draft specifically warning that authors SHOULD NOT add tabindex
values greater or equal to zero to non-interactive elements.
https://w3c.github.io/html/editing.html#the-tabindex-attribute

Some discussion on this change here:
https://twitter.com/stevefaulkner/status/789885665253163008

Generally, it's confusing for keyboard users in general (as by default
only interactive controls/widgets receive focus). It's further
problematic for users of assistive technologies, as these
non-interactive elements, when focused, also lack a sensible role (since
they're non-interactive, and usually are <div>s, <span>s or similar that
don't get any special announcement of role by AT).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Mallory
Date: Fri, Oct 28 2016 3:03AM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

As a non-assistive-tech keyboard user, what I would want are sensible
skip links.

And while I tend not to see it anywhere, when I have some course
software where as a student
I'm expected to be able to move from like a sidebar to a main part of
the page (like changing
an image using controls in a sidebar, then going to the main page to
answer a question
about it, and back again), I would like skip links there as well.
*possibly* a keyboard shortcut
just for switching between areas if the user is expected to do that for
each question might
be worth it, but still prefer skip links.

This allows navigation, uses truly interactive controls (who are
natively focusable and
have roles and names), doesn't get in the way of mouse users, doesn't
add a bazillion
tab stops for sighted keyboarders, and probably would even be helpful to
a fully blind
SR user (and I can't speak for other Mag users but on a sparse-looking
page with lots
of whitespace, having skip links would help me find all the areas I need
to get to
quickly as that's faster than searching as well).

cheers,
_mallory

--
Mallory
= EMAIL ADDRESS REMOVED =

On Fri, Oct 28, 2016, at 12:03 AM, Patrick H. Lauke wrote:
> On 27/10/2016 20:04, Erik Conrad wrote:
>
> > I know that having a tabindex on non-interactive content is not a best
> > practice and may be unexpected or annoying for users who normally use the
> > keyboard to navigate, but as someone with experience in UI design but new
> > to accessibility, it seems like a fair trade off. I would greatly
> > appreciate any opinions about how wrong (or right?) I am about that.
>
> Coincidentally, I've just recently pushed a change to the W3C HTML5.2
> editor's draft specifically warning that authors SHOULD NOT add tabindex
> values greater or equal to zero to non-interactive elements.
> https://w3c.github.io/html/editing.html#the-tabindex-attribute
>
> Some discussion on this change here:
> https://twitter.com/stevefaulkner/status/789885665253163008
>
> Generally, it's confusing for keyboard users in general (as by default
> only interactive controls/widgets receive focus). It's further
> problematic for users of assistive technologies, as these
> non-interactive elements, when focused, also lack a sensible role (since
> they're non-interactive, and usually are <div>s, <span>s or similar that
> don't get any special announcement of role by AT).
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: JP Jamous
Date: Fri, Oct 28 2016 3:27AM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

Patrick,

Funny you mentioned this. I was in a meeting with UX and UI managers yesterday and I think my recommendations were not welcomed by all of my audience.

I was complaining about labels that were used as radio buttons. The devs completely masked them as radio buttons. As we were debating that, one thing came up that I took in consideration as I try to be open minded. A radio button is a radio button, you cannot style it with round corners or square ones or make it look cool. To achieve that desirable outcome they do that with Divs and other elements.

Of course, JAWS and NVDA were having issues with the focus. JAWS would repeat the text a few times stating unselected and selected. So go figure out what status the radio button is in. NVDA, on the other hand, would not state anything as I up or down arrow through the list. However, visually it was changing between the radio buttons because of the tabindex that was applied to the label. In other words, it is receiving keyboard commands and not necessary NVDA commands.

We settled on ensuring that devs do not approach this concept like that anymore. Stick to proper semantic.

I continue to run into buttons and links and all kinds of elements that are masked as another element. Personally, I think it is pathetic. We have DOM elements that we are masking as other DOM elements.

I wish W3 would come out with an update for HTML 5 and add an element called object and that can be only to create a custom control. That way browsers can provide keyboard access to it, SR manufacturers can provide support for it and so on.

Trust me, we are not the only folks who are unhappy with that approach. SEO managers frown big time on things similar to that as they backfire on SEO.

I hope we can overcome this issue someday.

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick H. Lauke
Sent: Thursday, October 27, 2016 5:04 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Tab navigation for non-interactive content?

On 27/10/2016 20:04, Erik Conrad wrote:

> I know that having a tabindex on non-interactive content is not a best
> practice and may be unexpected or annoying for users who normally use
> the keyboard to navigate, but as someone with experience in UI design
> but new to accessibility, it seems like a fair trade off. I would
> greatly appreciate any opinions about how wrong (or right?) I am about that.

Coincidentally, I've just recently pushed a change to the W3C HTML5.2 editor's draft specifically warning that authors SHOULD NOT add tabindex values greater or equal to zero to non-interactive elements.
https://w3c.github.io/html/editing.html#the-tabindex-attribute

Some discussion on this change here:
https://twitter.com/stevefaulkner/status/789885665253163008

Generally, it's confusing for keyboard users in general (as by default only interactive controls/widgets receive focus). It's further problematic for users of assistive technologies, as these non-interactive elements, when focused, also lack a sensible role (since they're non-interactive, and usually are <div>s, <span>s or similar that don't get any special announcement of role by AT).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Fri, Oct 28 2016 3:35AM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

That´s where ARIA comes in handy.
Use ARIA to mark custom elements as radi buttons and to group them.
Then use Javascript for keyboard interaction.
I´ve done this a few times with developers, and support with A.T. is
getting dece.t
See one of the examples I worked on at Deque University´s custom form
controls widget
https://dequeuniversity.com/library/aria/custom-controls/sf-checkboxes-radios
(you can copy the entire markup out of there and into a text editor if
you want to play with it).

On 10/28/16, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> Patrick,
>
> Funny you mentioned this. I was in a meeting with UX and UI managers
> yesterday and I think my recommendations were not welcomed by all of my
> audience.
>
> I was complaining about labels that were used as radio buttons. The devs
> completely masked them as radio buttons. As we were debating that, one thing
> came up that I took in consideration as I try to be open minded. A radio
> button is a radio button, you cannot style it with round corners or square
> ones or make it look cool. To achieve that desirable outcome they do that
> with Divs and other elements.
>
> Of course, JAWS and NVDA were having issues with the focus. JAWS would
> repeat the text a few times stating unselected and selected. So go figure
> out what status the radio button is in. NVDA, on the other hand, would not
> state anything as I up or down arrow through the list. However, visually it
> was changing between the radio buttons because of the tabindex that was
> applied to the label. In other words, it is receiving keyboard commands and
> not necessary NVDA commands.
>
> We settled on ensuring that devs do not approach this concept like that
> anymore. Stick to proper semantic.
>
> I continue to run into buttons and links and all kinds of elements that are
> masked as another element. Personally, I think it is pathetic. We have DOM
> elements that we are masking as other DOM elements.
>
> I wish W3 would come out with an update for HTML 5 and add an element called
> object and that can be only to create a custom control. That way browsers
> can provide keyboard access to it, SR manufacturers can provide support for
> it and so on.
>
> Trust me, we are not the only folks who are unhappy with that approach. SEO
> managers frown big time on things similar to that as they backfire on SEO.
>
> I hope we can overcome this issue someday.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Patrick H. Lauke
> Sent: Thursday, October 27, 2016 5:04 PM
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Tab navigation for non-interactive content?
>
> On 27/10/2016 20:04, Erik Conrad wrote:
>
>> I know that having a tabindex on non-interactive content is not a best
>> practice and may be unexpected or annoying for users who normally use
>> the keyboard to navigate, but as someone with experience in UI design
>> but new to accessibility, it seems like a fair trade off. I would
>> greatly appreciate any opinions about how wrong (or right?) I am about
>> that.
>
> Coincidentally, I've just recently pushed a change to the W3C HTML5.2
> editor's draft specifically warning that authors SHOULD NOT add tabindex
> values greater or equal to zero to non-interactive elements.
> https://w3c.github.io/html/editing.html#the-tabindex-attribute
>
> Some discussion on this change here:
> https://twitter.com/stevefaulkner/status/789885665253163008
>
> Generally, it's confusing for keyboard users in general (as by default only
> interactive controls/widgets receive focus). It's further problematic for
> users of assistive technologies, as these non-interactive elements, when
> focused, also lack a sensible role (since they're non-interactive, and
> usually are <div>s, <span>s or similar that don't get any special
> announcement of role by AT).
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > http://webaim.org/discussion/archives
> >
> > > > >


--
Work hard. Have fun. Make history.

From: Jonathan Avila
Date: Fri, Oct 28 2016 7:57AM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

> Coincidentally, I've just recently pushed a change to the W3C HTML5.2 editor's draft specifically warning that authors SHOULD NOT add tabindex values greater or equal to zero to non-interactive elements.

Sam Joehl and I had a twitter conversation with Steve that doesn't seemed to be listed in the thread where we list some situations where it is important. For example, for terms of service or scrolling areas. If the scrolling area is not keyboard focusable or there is not keyboard focusable content in it a keyboard only user or a user of speech recognition will not be able to access that content outside the scrollable area.

There also may be some other readonly type content that isn't in a readonly field like redemption or promotion codes or other things that may need to be copied via the keyboard where the user may not have access to caret browsing, etc.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick H. Lauke
Sent: Thursday, October 27, 2016 6:04 PM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Tab navigation for non-interactive content?

On 27/10/2016 20:04, Erik Conrad wrote:

> I know that having a tabindex on non-interactive content is not a best
> practice and may be unexpected or annoying for users who normally use
> the keyboard to navigate, but as someone with experience in UI design
> but new to accessibility, it seems like a fair trade off. I would
> greatly appreciate any opinions about how wrong (or right?) I am about that.

Coincidentally, I've just recently pushed a change to the W3C HTML5.2 editor's draft specifically warning that authors SHOULD NOT add tabindex values greater or equal to zero to non-interactive elements.
https://w3c.github.io/html/editing.html#the-tabindex-attribute

Some discussion on this change here:
https://twitter.com/stevefaulkner/status/789885665253163008

Generally, it's confusing for keyboard users in general (as by default only interactive controls/widgets receive focus). It's further problematic for users of assistive technologies, as these non-interactive elements, when focused, also lack a sensible role (since they're non-interactive, and usually are <div>s, <span>s or similar that don't get any special announcement of role by AT).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Fri, Oct 28 2016 8:05AM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

On 28/10/2016 14:57, Jonathan Avila wrote:

> Sam Joehl and I had a twitter conversation with Steve that doesn't
> seemed to be listed in the thread where we list some situations where
> it is important. For example, for terms of service or scrolling
> areas. If the scrolling area is not keyboard focusable or there is
> not keyboard focusable content in it a keyboard only user or a user
> of speech recognition will not be able to access that content outside
> the scrollable area.

And this is why the warning is a "SHOULD NOT", rather than a "MUST NOT".
If you can justify the use of tabindex greater than zero on something
with good conscience, then that's fine.

> There also may be some other readonly type content that isn't in a
> readonly field like redemption or promotion codes or other things
> that may need to be copied via the keyboard where the user may not
> have access to caret browsing, etc.

But then why isn't it in a readonly field?

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jonathan Avila
Date: Fri, Oct 28 2016 8:06AM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

> But then why isn't it in a readonly field?

So you can visually format it more than can be done with input @readonly.

Jonathan

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Patrick H. Lauke
Sent: Friday, October 28, 2016 10:05 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Tab navigation for non-interactive content?

On 28/10/2016 14:57, Jonathan Avila wrote:

> Sam Joehl and I had a twitter conversation with Steve that doesn't
> seemed to be listed in the thread where we list some situations where
> it is important. For example, for terms of service or scrolling
> areas. If the scrolling area is not keyboard focusable or there is
> not keyboard focusable content in it a keyboard only user or a user of
> speech recognition will not be able to access that content outside the
> scrollable area.

And this is why the warning is a "SHOULD NOT", rather than a "MUST NOT".
If you can justify the use of tabindex greater than zero on something with good conscience, then that's fine.

> There also may be some other readonly type content that isn't in a
> readonly field like redemption or promotion codes or other things that
> may need to be copied via the keyboard where the user may not have
> access to caret browsing, etc.

But then why isn't it in a readonly field?

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Fri, Oct 28 2016 8:23AM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

On 28/10/2016 15:06, Jonathan Avila wrote:
> So you can visually format it more than can be done with input @readonly.

I'm not aware of anything style-wise that can't be achieved on an
input...but I'll take your word for it. And again, if you feel there is
a strong enough case that can be argued, then the developer can safely
ignore the "SHOULD NOT" wording in the warning.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Fri, Oct 28 2016 10:23AM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | Next message →

1. Jonathan, can you post that conversation here, or link to it, I'd
like to read it.
Yes, there are occasionally reasons for sometimes using tabindex="0",
Ihave yet to find any reason for using tabindex>0 (it always ends up a
mess).

2. Wel, if you need to format a disabled formfield you can use
aria-disabled="true" use CSS to make it look disabled, and use
Javascript to make sure user can't interact with it.
In any case, isn't it more politically correct to call them "form
fields with disabilities" rather than "disabled form fields"? ;)
-B



On 10/28/16, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 28/10/2016 15:06, Jonathan Avila wrote:
>> So you can visually format it more than can be done with input @readonly.
>
> I'm not aware of anything style-wise that can't be achieved on an
> input...but I'll take your word for it. And again, if you feel there is
> a strong enough case that can be argued, then the developer can safely
> ignore the "SHOULD NOT" wording in the warning.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.

From: Jonathan Avila
Date: Fri, Oct 28 2016 10:38AM
Subject: Re: Tab navigation for non-interactive content?
← Previous message | No next message

> 1. Jonathan, can you post that conversation here, or link to it, I'd like to read it.

https://twitter.com/stevefaulkner/status/780350480283238400

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!


-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Friday, October 28, 2016 12:23 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Tab navigation for non-interactive content?

1. Jonathan, can you post that conversation here, or link to it, I'd like to read it.
Yes, there are occasionally reasons for sometimes using tabindex="0", Ihave yet to find any reason for using tabindex>0 (it always ends up a mess).

2. Wel, if you need to format a disabled formfield you can use aria-disabled="true" use CSS to make it look disabled, and use Javascript to make sure user can't interact with it.
In any case, isn't it more politically correct to call them "form fields with disabilities" rather than "disabled form fields"? ;) -B



On 10/28/16, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 28/10/2016 15:06, Jonathan Avila wrote:
>> So you can visually format it more than can be done with input @readonly.
>
> I'm not aware of anything style-wise that can't be achieved on an
> input...but I'll take your word for it. And again, if you feel there
> is a strong enough case that can be argued, then the developer can
> safely ignore the "SHOULD NOT" wording in the warning.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.