Freecodecamp: Applied Accessibility input with tabindex is not selected when pressing 'tab'

Created on 16 May 2019  路  3Comments  路  Source: freeCodeCamp/freeCodeCamp

Describe your problem and how to reproduce it:
The info for the challenge said that..

Setting a tabindex="1" will bring keyboard focus to that element first. Then it cycles through the sequence of specified tabindex values (2, 3, etc.), before moving to default and tabindex="0" items.

And the challenge is..

Camper Cat has a search field on his Inspirational Quotes page that he plans to position in the upper right corner with CSS. He wants the search input and submit input form controls to be the first two items in the tab order. Add a tabindex attribute set to "1" to the search input, and a tabindex attribute set to "2" to the submit input.

However, after I put tabindex on the both the input and the button, then I press "TAB" it isn't the first thing that is selected! In fact, it's not even selected! And I had successfully finished the course. Also, I already checked the hint and I think it's trying to do the opposite.

But again, as I'm a newbie, I don't know wheter I'm wrong or right, I just wanted to ask is this the desired goal?

Thank you.

Add a Link to the page with the problem:
Applied Accessibility: Use tabindex to Specify the Order of Keyboard Focus for Several Elements

Tell us about your browser and operating system:

  • Browser Name: Mozilla
  • Browser Version: 66.0.5 (64-bit)
  • Operating System:
    LSB Version: n/a
    Distributor ID: ManjaroLinux
    Description: Manjaro Linux
    Release: 18.0.4
    Codename: Illyria
learn discussing

Most helpful comment

I don't think you did anything wrong. In fact, it was helpful that you looked into how it actually behaved and let us know it was a little weird!

The challenge isn't wrong exactly, but I think the issues with positive indices could be highlighted a bit more. Perhaps by inviting campers to tab around the preview panel and see the strange behaviour you noticed. This will need a bit more discussion before we try changing the challenge, though.

All 3 comments

@jippy89 So, positive tabindices are weird. If you follow the instructions, click on the preview pane and shift-tab (i.e. tab backwards), it should focus on the submit button. Shift-tabbing again takes you to the search box. Why exactly mouse clicks put you in the middle of the tab order isn't clear to me.

If you navigate to the preview pane entirely by the keyboard, it should focus in the expected order. The search box comes first, then the button and finally the three links. The easiest way I found to see this was to click on the test output box (below the editor) and tab from there.

_is this the desired goal?_

Probably not. I defer to webaim here. In particular

tabindex="1" (or any number greater than 1) defines an explicit tab order. This is almost always a bad idea.

I think that we would be better off using this challenge to warn about the problems that come along with using positive values for tabindex.

Oh ok, thanks for clearing that up. I did try your suggestion by clicking the test output box first then tab from there, and it works like it used to be (as it should in instruction).

But let me take a conclusion, so there's a mistake with the context in the course and it isn't my fault?

I don't think you did anything wrong. In fact, it was helpful that you looked into how it actually behaved and let us know it was a little weird!

The challenge isn't wrong exactly, but I think the issues with positive indices could be highlighted a bit more. Perhaps by inviting campers to tab around the preview panel and see the strange behaviour you noticed. This will need a bit more discussion before we try changing the challenge, though.

Was this page helpful?
0 / 5 - 0 ratings