Since when?

Keyboarding and more...

[chewy]

Since when did someone decide to remove keyboard shortcuts?

When did the active cursor stop jumping to the correct box where a simple "Enter" would finish the actions?

Who decided that the mouse was the preferred (and in some cases only) way to navigate?

Does anyone else notice these things?

-C

[ronin]

I agree that keyboard-operability is insufficiently emphasised - especially when it comes to websites and web-apps.

Over the last two decades, I've become more practised (at a glacial pace) at web-usability and web-accessibility and it only struck me earlier this year that any web-app I write really ought to have keyboard navigability and operability as standard.

As such, I've recently added it to my fundamental best practices list.

That is, any website or web-app I write should include, as standard:

- HTML5 Semantic Sectioning Elements (since 2010)
- Responsive Web Design (since 2015)
- UI Graphical Elements written in SVG (since 2016)
- BEM-based CSS (since 2018)
- Progressive Web App (since 2018)
- WebP Images (since 2022)
- Keyboard Navigability and Operability (since 2022)

[tangor]

There's the opposite side of things:

How many users ever learn keyboard shortcuts? The device of choice is a smart phone or tablet (without keyboards). The mouse (or fingertip) is the lazy path of least insistence.

[lucy24]

Since when did someone decide to remove keyboard shortcuts?

From what OS or application?

[chewy]

all..... Windows stuff. I know, that's my first mistake!

[not2easy]

By any chance is this related to that problematic [webmasterworld.com] Dell keyboard?

[chewy]

Nope. Similar but not the same. One's been happening for 10+ years, the other is very recent.

[Sgt_Kickaxe]

Could it be related to browser overlays(in app browsers)?

Something else that is rather new is you visiting a site with your browser and the site shows you your browser in their browser envelope. I imagine tracking mouse movement would be easier than tracking shortcut use.

This is what Facebook is saying about their in app browsers. It's now possible for someone to visit your site without leaving Facebook's browser, but do the shortcuts work? - [facebook.com...]

[ronin]

How many users ever learn keyboard shortcuts?

I think this is a fair question, but ultimately it may not be relevant.

Keyboard controls ought to be there (I have concluded) even when most people use touchscreens.

Otherwise you get a chicken / egg case where the data for most websites (which don't have keyboard controls) shows (unsurprisingly) that most people don't use keyboard controls - so the data doesn't justify adding them. It might be the case that adding keyboard controls across the web landscape provokes an uptick in the usage frequency of such controls.

Imagine a circular series of web pages with the following navigation mechanisms:

1) On a non-touch laptop / desktop, clickable tabs on the left hand and right hand edges of the screen load the previous or next page

2) On a touchscreen tablet / mobile phone, swipe gestures load the previous or next page

Now add previous page / next page functionality to the left and right arrow keys on the keyboard.

For touchscreen tablet / mobile phone users, this added functionality makes no difference.

And, sure, some people on non-touch laptops / desktops will still persist with 1).

But, I imagine that, amongst others, the arrow keys will become increasingly popular - not least on the basis that they are far more convenient than moving your mouse all the way to one edge of a landscape screen and then all the way to the other edge.

[ronin]

I've been doing some tabindex related work in the last 24hrs and I thought I'd come back to this thread with two points.

The first is something I've only just come across and I'm not sure how I ever missed it before.

1) MDN states:

Accessibility concerns
Avoid using the tabindex attribute in conjunction with non-interactive content to make something intended to be interactive focusable by keyboard input. An example of this would be using a <div> element to describe a button, instead of the <button> element.

Interactive components authored using non-interactive elements are not listed in the accessibility tree. This prevents assistive technology from being able to navigate to and manipulate those components. The content should be semantically described using interactive elements (<a>, <button>, <details>, <input>, <select>, <textarea>, etc.) instead. These elements have built-in roles and states that communicate status to the accessibility that would otherwise have to be managed by ARIA.

Source: [developer.mozilla.org...]

This basically means: resist the temptation to turn <div> elements into makeshift buttons; style a <button> element, instead. Your <div> won't be picked up by the accessibility tree, whereas your <button> always will.

======

The second has been conventionally accepted advice for quite a while now, but... I'm no longer convinced it's entirely right.

2) MDN states:

Avoid using tabindex values greater than 0. Doing so makes it difficult for people who rely on assistive technology to navigate and operate page content. Instead, write the document with the elements in a logical sequence.

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

The Paciello Group states:

Avoid using tabindex=1+ [...] It’s when tabindex is set to a positive integer that things get problematic. It imposes a tab order on the content that bears no resemblance to the expected tab order.

Source: https://www.tpgi.com/using-the-tabindex-attribute/

But what about imposing a tab order on the content so that it does bear a resemblance to the expected tab order ?

I definitely think there are some situations where, for compelling reasons, segments of UI will be marked up in a much lower position in your HTML from where they appear in the viewport.

Take for instance an <aside> element containing a row of buttons which displays as position: fixed towards the top-right of the page.

In this case, yes, the intention is to keep the <aside> element permanently visible, to give it some visual priority. But that doesn't mean that it has content priority - it would probably be surprising if that <aside> weren't marked up quite a long way down the HTML document.

However, if you then use tabindex="0" (or, for interactive elements, no tabindex attribute) everywhere, the keyboard user is going to be tabbing for a loooong time, before they reach that part of the UI (because it's a long way down the document).

In this situation, why not, instead, explicitly give the first few tab-able elements a tabindex="1", then give the child elements of the <aside> a tabindex="2" and then you're free to let everything else continue with a tabindex="0" (or, for interactive elements, no tabindex attribute) ?

[ronin]

[...] it only struck me earlier this year that any web-app I write really ought to have keyboard navigability and operability as standard.

I wrote that ^^^ further up the thread, but I note that MDN regards keyboard navigability and operability as nothing short of essential when it comes to accessibility:

To be fully accessible, a web page must be operable by someone using only a keyboard to access and control it. This includes users of screen readers, but can also include users who have trouble operating a pointing device such as a mouse or trackball, or whose mouse is not working at the moment, or who prefer to use a keyboard for input whenever possible.

Source: [developer.mozilla.org...]

I wonder how all that goes down with the JavaScript front-end framework crowd?

React / Angular etc. developers have always seemed (to me) like... a different constituency.

If CSS doesn't come particularly naturally to a significant number of JS-first web-developers (at least not in the same way it does to HTML-first web-developers) I wonder if Accessibility feels to them like a similarly - or even more - alien concern?