Dev.to WebDev ๐Ÿ›  Dev ๐Ÿ‘ 0 ๐Ÿ“– 5 min read

Driving the OnePassApps Studios With a Keyboard: Tab Order, Live Regions and Focus Rings

I work on OnePassApps, so this is a measurement of our own product in the live app, not a review of someone else's code. Every OnePassApps Studio is a form: a file or a paste box, some options, a result. That makes the

I work on OnePassApps, so this is a measurement of our own product in the live app, not a review of someone else's code.

Every OnePassApps Studio is a form: a file or a paste box, some options, a result. That makes the seven studio pages a natural place to check keyboard and assistive-technology access, because each one has to be usable without a mouse. No channel here had covered accessibility before, so I measured it in the live app and wrote down what I found, including the part that did not come out well.

What I measured, and how

Seven routes: /studios/image, /studios/audio, /studios/files, /studios/text, /studios/data, /studios/icons and /studios/colour. One build, one browser, one session, signed out.

I read the accessibility properties straight out of the DOM, and I drove the pages with real Tab and ArrowRight key events rather than calling focus() from a script, so the focus order below is the order a keyboard user actually gets.

I did not run a screen reader. Everything below is what the DOM exposes to one.

The tool switcher is a real radio group

On the Data Studio page the eleven tools - Viewer, Sort / filter, Columns, Duplicates, Merge, Split, To JSON, Formatter, Validator, To CSV and YAML - are a radiogroup. Each tool is a button with role="radio", the group carries role="radiogroup", and the selected tool carries aria-checked="true".

The keyboard behaviour is right. Tab moves focus into the group once, ArrowRight moves the selection, and the selection follows the focus: from Viewer, one ArrowRight moved to Sort / filter and a second to Columns, with aria-checked moving with it. The other ten tools sit at tabindex="-1", so the group is one tab stop rather than eleven.

Underneath the visible buttons sit native radio inputs with aria-hidden="true" and tabindex="-1". Those are proxies for the browser's own form state, and they are correctly hidden from the accessibility tree.

The same pattern holds on the other six pages: ten radios on Image Studio (seven tools plus the PNG, JPEG and WebP choices), four on Audio Studio, seven on File Studio, eight on Text Studio, eight on Icon Studio and four on Colour Studio.

The tab order on a studio page

Tabbing through the Data Studio from the top of the document:

  1. Skip to content
  2. Data Studio - the logo link
  3. Viewer - the tool radio
  4. the paste box, placeholder "Paste local data"
  5. Input limits and privacy
  6. Auto detect - the delimiter chooser, role="combobox"
  7. Browse files
  8. Get started
  9. See plans
  10. Dismiss free promotion notice

Then focus left the page, and the next Tab started again at Skip to content.

Every studio page carries that skip link, and each page also has a nav, a main and an aside landmark, one visible h1 naming the studio and the tool, and h3 headings over the steps - Source, Options and Result, with a couple of pages adding their own.

Nothing you can reach is unnamed

Across the seven pages I counted 120 buttons and 84 links. Every one of them has an accessible name: the count of unnamed buttons was 0 on every route, and the count of unnamed links was 0 too.

The one visible control whose name comes from a fallback is the paste box, which is named by its placeholder, "Paste local data". Placeholders disappear the moment you type, so that one would be better as a real label.

The file picker is reached through a button, and the button has a name

The raw file inputs on the Data Studio page have no id, no associated label and no aria-label, and each renders one pixel by one pixel. They also sit at tabindex="-1", so the keyboard never lands on them.

What the keyboard lands on is a button labelled "Browse files" with tabindex="0", which is the accessible route to the same control. Each route accepts its own types: the image picker lists JPEG, PNG and WebP, the audio picker takes audio formats plus mp4, mov, mkv and ts, and the icon picker takes only .svg and image/svg+xml.

Results get announced

I pasted a two-row CSV and pressed Parse CSV. Two polite live regions updated. One read "Loaded 2 rows and 2 columns." and the other "Parsed in 206 ms". The result stage itself showed "2 rows ยท 2 columns ยท no parsing issues" and "Delimiter found Comma", with the preview listing id as NUMBER and name as TEXT.

One gap: no focus ring on the two controls you type into

This is the measurement I did not expect, so I am writing it down carefully.

Focusing the visible controls with real Tab keypresses on the Data Studio page, the buttons and the links computed to a solid 2px outline in rgba(242, 243, 244, 0.92). The paste box and the delimiter chooser computed to outline-style: none, with a fully transparent box-shadow. On the surfaces I measured, the focus indicator is there on the buttons and absent on the two controls you actually type into.

One caveat before anyone reads that as a verdict: I read the computed style of the elements themselves, so a ring drawn on a pseudo-element would not have appeared in my numbers. Treat it as one measurement on one page.

Also worth knowing

The decorative images on a studio page carry an empty alt attribute, which marks them as decorative rather than describing them. The number of visible focusable elements per page ranges from 31 on the Audio Studio to 51 on the Text Studio.

Limits, stated honestly

One build, one browser, one day, signed out, one session on one machine. No screen reader was involved - this is what the DOM exposes, not what VoiceOver or NVDA actually says out loud. I measured the seven studios, not the two hosted apps. I walked the tab order in full on the Data Studio; on the other pages I counted focusable elements rather than stepping through them one at a time. The focus-ring gap was measured on the Data Studio only. I did not test touch, zoom, high-contrast modes, or any assistive technology against the live app.

Try it yourself

The Data Studio, if you want to check any of this with your own keyboard: https://app.onepassapps.com/studios/data?utm_source=devto&utm_medium=post&utm_campaign=keyboard-access&utm_content=studio-link

And the app guides, which spell out what each app does and does not do: https://app.onepassapps.com/guides?utm_source=devto&utm_medium=post&utm_campaign=keyboard-access&utm_content=guides-link

๐Ÿ“ฐ Read the original article on Dev.to WebDev

Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes โ€” full credit and traffic to the original publisher.