tabIndex doesn't work for values more than 0

[gentlee]

Is there an existing issue for this?

• I have searched the existing issues

Describe the issue

tabIndex works only when it is set to value -1 or 0.

Expected behavior

tabIndex should behave the same as for corresponding html tag - work with values from - 1 to 32767.

Steps to reproduce

Pass tabIndex={999} to any component, this attribute won't appear in html.

Test case

Additional comments

Needed when for example I want to move header back button to the end of focus order.

[necolas]

tabIndex works only when it is set to value -1 or 0.

This is by design, and matches web accessibility recommendations

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex

[gentlee]

@necolas

1. It is a recommendation, and recommendations work 99% percent of time, but there is a 1% when you need to add hack to make something work better. That's why tabIndex is not deprecated.
2. RNW should not have any additional business logic besides that is needed for it to work, it should behave totally the same as underlying technologies. If you want to make people know about some recommendations, there could be just a warning.
3. Here is an article from deque univercity accessibility course:
   So even one of the best places to learn accessibility confirms that it is better to avoid setting tabindex, but sometimes it makes sense.
4. I provided an example where I need that:

Needed when for example I want to move header back button to the end of focus order.

[Jackman3005]

@gentlee I agree that we should have the ability to set tabIndex greater than 0. I see the risk that devs can provide worse accessibility by abusing this feature, but it's supported by all browsers and is long-standing functionality that also allows devs to provide better accessibility and experiences in some cases for their app.

I don't think it make sense to enforce (without workaround) best practices like this at the RNW layer. I do think it's a good idea to help devs make the right choices though. We could make it more clear that it should be avoided or treat it as an advanced feature by adjusting the API. Also could be worth providing warning messages or adding a linter to the default preset to raise awareness when setting tabindex > 0.

Some ideas for an API that communicates more than just the numerical value of the field:

tabIndex={true}                  // "focusable" -> 0
tabIndex={false}                 // "not focusable" -> -1

tabIndex={TabIndex.DEFAULT}      // "focusable" -> 0
tabIndex={TabIndex.HIDDEN}       // "not focusable" -> -1
tabIndex={TabIndex.PRIORITY}     // "focusable" -> 1
tabIndex={TabIndex.value(2)}     // "focusable" -> 2

For the TabIndex enum idea, they could all basically just map to the numbers from before, but you could make the Typescript types only accept the Enum so that it becomes the standard way to provide tab indexes. The enum could have short documentation for each value including warnings/links to accessibility documentation on why to avoid > 0 tabIndexes.

For our use-case, we have a page with some header elements and then a list view with thousands of entries and a sticky footer button that we want to have tab priority above the list so that users can tab to it without having to go through all the entries. If there is another way to accomplish this, that would be great to know!

[Arjan-Zuidema]

I don't think this should be "fixed" in react-native-web and just use the values as-is. If a developer wants to use any other value than -1 or 0 leave it up to them. Now we are forced to use an opinionated value to tabIndex