Monday, October 02, 2017

Is disclosing ADHD a good idea? Let's find out

It's time. In recognition of World Mental Health Day and ADHD Awareness Month, I've decided to start telling everybody about my ADHD brain.

For people who know me, the revelation that I go off on mental tangents might be the least surprising news of the day. Yet I struggled with the decision to say "I have ADHD" out loud in a public forum, and I won't claim that disclosure is for everybody.

According to a 2015 survey of ADHD disclosure, respondents were evenly split on whether outcomes in the workplace were positive or negative. "The severity of negative outcomes varied. Some were fired, passed over for promotion, ridiculed, or the ADHD disclosure was ignored by the employer and no attempts were made to implement or offer accommodations."

On the other hand, it's easier and safer for me to talk about my ADHD than it is for a lot of other people. As a white male in the United States, I started at a spot near the front of the line which I never earned. Maybe because of a strong moral compass that I got from my parents, my impulsivity has always made me look like a goody-goody, instead of taking me in less productive directions. I'm blessed with strong literacy and analytical skills, for which I'm particularly grateful since others with ADHD are not so fortunate. Today I work in a growing specialty field called digital accessibility (auto-play video) where my colleagues celebrate our diversity every day. With a lot of luck, and some hard work especially in recent years, my life looks like a success story according to today's mainstream norms.

The stigmas around ADHD are unacceptable, and hiding just reinforces them. So if I don't take this risk, who will?

Ask me questions. Don't worry about how to phrase the questions. It'll be fine. I used to be less-than-completely comfortable talking about this, but only because I was managing who knows and who doesn't. Now that I've blogged about it, I've shed that layer of hesitation.

Friday, February 26, 2016

Can JavaScript set a Sequential Focus Navigation Starting Point?

This is a follow-up from my last blog post. Should a web author be able to explicitly set a Sequential Focus Navigation Starting Point using JavaScript?

There are several reasons why the answer should be "yes."

It can improve user experience in some cases

Today, for accessibility it's often necessary to set focus on a div or static text. If browsers and assistive technologies will provide a consistent experience for anchor links, then instead of setting focus on non-actionable content, it would be more like native browser behavior to set a Sequential Focus Navigation Starting Point. In such cases users would expect to see the element in the viewport, so the author should also use Element.scrollIntoView().

Less often, this same technique can solve a usability problem when JavaScript sets focus on a text input. In devices with virtual keyboards (iOS Safari at least), input.focus() causes the virtual keyboard to appear. This is appropriate in some cases, where the design intent is to strongly prompt the user to enter something. But what if the intent is only to start the user at a logical spot in the form? For example, after the user cancels out of a modal dialog. In this case using JavaScript to set a Sequential Focus Navigation Starting Point would provide a better experience.

It conforms to WCAG 2.0 as well as anchor links do

I've never heard of failing Success Criterion 2.4.3 Focus Order or 2.4.7 Focus Visible because of the browser-default behavior of anchor links. This JavaScript technique would do the same thing.

There are good technical precedents

Setting window.location.href creates the same effect as a user clicking a link to a new page.

In most browsers, Element.focus() creates the same effect as a user clicking an anchor link to land on a focusable element.

So if JavaScript can create the effect of an anchor link landing on a non-focusable element, it would be very consistent with those existing capabilities.

It might already work

When an element has focus, then the expected behavior of Element.blur() -- after Chromium issue 454172 -- is to create a Sequential Focus Navigation Starting Point.

So what should happen if the author invokes Element.blur() on an element that does not currently have focus? The logical consequence would be for this element to become the Sequential Focus Navigation Starting Point.

I could live with this counterintuitive behavior of Element.blur(), like we've all learned to live with tabindex="-1". I'm also open to adding a more aptly named method to browser-native JavaScript.

Tuesday, February 23, 2016

The "sequential focus navigation starting point" in WebKit and Chromium

Both from a user perspective and from a technical perspective, I like the way Chromium is formalizing the "sequential focus navigation starting point".

A few highlights of this change:
If a navigation to a url with fragment identifier happened, an element pointed by the fragment is set as sequential focus navigation starting point.
In other words, anchor links like #skip_to_main will now work for keyboard users, without any JavaScript. We've only been waiting for this since 1990!
If the element pointed by sequential focus navigation starting point is removed from the document tree, a point where there was the element at would be the starting point.
This is good for accessibility in modern web sites, such as single-page apps. We'll first need to see some follow-on improvements in browsers and assistive technologies, but eventually this might allow web authors to simplify focus management, as DOM elements are removed and changed.
Implementation: Sequential focus navigation starting point is represented as a Range object, and it is owned by a Document.
This is the technically elegant part. It builds on existing patterns, to achieve something new.

Now I have a few questions for the community. The behavior is already looking good for users, so these questions are mainly geared toward supporting web authors.
  1. There's a standard and widely supported Range object. What's the interface to access this new special Range? Maybe as a property of the Document?
  2. The related WebKit ticket points out that Gecko (Firefox) and Trident (Internet Explorer) already have their own implementations. Can this interface be standardized across browsers, or is it too late for that?
  3. As the Chromium issue points out, there are several kinds of scripted behaviors and user behaviors which cause the Sequential Focus Navigation Starting Point to occur. Although not mentioned specifically, presumably the point could change any number of times before any DOM element gets focus. Given that these various behaviors all lead to a single thing happening from a user perspective, could we fire a device-independent JavaScript events? It would be a mouthful -- "onSequentialFocusNavigationStartingPointChange" (?!?) -- but you get the idea.
  4. Would it make sense for this Range object to be the relatedTarget of blur events?
Finally, I have a couple of more questions that are geared toward making life easier for developers of browsers and assistive technologies.
  1. Is there a consistent behavior in browsers for caret navigation?
  2. What are the use cases for mobile browsers?
  3. Similar to the JavaScript event questions -- can there be a related event in accessibility APIs? Screen readers have tried to compensate for browser differences, but this could lead to more consistency in the future.