There have been reasons to leave Twitter since its inception. But it's increasingly compelling to post somewhere else.

Why read about what random people do all day? In the spring of 2007, I wasn't sure why I would join Twitter. All the cool web folks at that year's SXSW Interactive had started using (and hyping) it. I worked at a small web agency at the time. My colleagues convinced me, I think. So I made an account on this new website that had just one text field with the question ‘What are you doing?’.

When I started, I mostly bored my readers with facts like “I drank a cup of tea” or “waiting for a bus”. Mentions and retweets didn't exist yet. For the first, maybe, 5 years, my account was private and I had way under 100 followers. I tweeted mostly in Dutch, even in Frisian sometimes. There was a generous API so you could trivially display tweets on your own site. There were local in-person Twitter meetups, at least where I live, to hang out with Twitter folks, including one that had Dries Roelvink perform.

Twitter homepage in 2007, the logo was a piece of art

In the years after, the platform expanded beyond the web developer crowd and interesting journalists, authors, musicians came. I used the platform more and more to follow folks I saw speak at conferences. Over the years I found a collection of hundreds of people whose stuff I really enjoyed reading. On web development, but also other interests. Some posted often, others occassionally. Either way, I learned so much from the tweets, links to other sites, discussions and what not. More people started following me too, and I managed to develop real friendships. My DMs got busier too. Twitter, the platform got useful new features, but ultimately, it's the people that attracted me to the platform and people that kept me on there.

Yet, there were always compelling reasons to leave. The platform and tweets became more engagement-focused, the Twittersphere started to attract (and reward) grifters. The algorithmic timeline was introduced, although that could be turned off.

Abuse also increased, especially for minorities on the platform. Under Jack Dorsey's leadership, Twitter systematically failed to act on reports of racist, homophobic and misogynist accounts, it made Twitter more dangerous to anyone not a cis white male, even got users in physical danger. Some of that was described in a 2018 Amnesty International report on Twitter called “A toxic place for women”, a document full of details on how the company failed to respect women's rights.

And then there was the risk of making content on a platform that you don't control. My friend Manuel got permanently suspended, for reasons unknown to him. I can only imagine what it was like for him to lose access, just like that. A lot of us tried to change the minds of “@TwitterSupport”, but until today, it wasn't resolved. For a lot of folks this situation was a wake up call to reconsider where they post. I realised my new ambition was to like, Zach, take ownership of my tweets.

Last week, I still didn't feel like leaving the platform just because the new owner was an arrogant troll with world views orthogonal to mine. I imagine more services I use have unpleasant owners. Last time I tried Mastodon, I didn't stay. The thing is, I don't even think I really believe in decentralised social networks, I would rather have all my friends in one pub than spread across pubs. I will probably find out I'm wrong about this, as the web at large was designed to be decentralised and it is one of the charms of it and arguably what made it so successful.

But then that new owner fired Twitter's entire accessibility team, its ethical AI team and large parts of trust and safety folks working on problems that have very real life consequences (like meddling in elections, spreading of conspiracy theories, hate crimes, impersonation), he unfolded plans for a new ‘Verified’ program that made the feature for sale rather than for security and then he recklessly and cruelly fired half of the staff (and seems to be trying to get some back)… it's chaos!

So I decided to go ahead and hang out elsewhere, at least to put my content there. That other place is ‘the Fediverse’, and it has a different focus:

the Fediverse is different: it isn’t trying to glue your eyeballs to the screen, and it’s harder for things to go viral. There is less media, fewer memes, no advertising. And there are humans explicitly in the loop: Mastodon instances are moderated on an instance-by-instance basis — and should an instance descend into a hellscape, it may find itself defederated. But because of all of this, there is also less opportunism, less trolling, less dunking on your enemies, less nastiness. So it also feels more relaxing, more earnest — and easier to put down.

(from Bryan Cantrill's Twitter, when the wall came down)

Maybe the decentralisation aspect could actually work. It's a bit like email.

It seems like the new owner and his behaviour is driving people in my bubble away from Twitter, towards the Fediverse, personal blogs, RSS and other platforms. Probably mostly in that bubble, but maybe it is a wider thing, time will have to tell. It's probably not the last exodus.

I didn't suddenly stop caring about the people I follow on Twitter, I understand not everyone wants to leave, so I will also stay on Twitter for the foreseable future. To catch up on tweets, to DM and to share posts like this one. But for the next while, I plan to hang around on Mastodon more.

---

Originally posted as Is this the last exodus from Twitter? on Hidde's blog.

Reply via email

There have been reasons to leave Twitter since its inception. But it is increasingly more compelling to do so.

Why read what random internet people are doing all day? In 2007, I wasn't sure why I would join Twitter that spring. All the cool web folks at SXSW that year had started using (and hyping) it. I worked at a small web agency and my colleagues convinced me, I think. So I made an account on this new website that had just one text field with the question ‘What are you doing?’.

When I started, I mostly shared things like that I drank a cup of tea or waited for a bus. Mentions and retweets didn't exist yet. For the first, maybe, 5 years, my account was private and I had way under 100 followers. I tweeted mostly in Dutch, even in Frisian sometimes. There was a generous API so you could trivially display tweets on your own site. There were local in-person Twitter meetups, at least where I live, to hang out with Twitter folks, including one that had Dries Roelvink perform.

In the years after, the platform expanded beyond the web developer crowd and interesting journalists, authors, musicians came. I used the platform more and more to follow folks I saw speak at conferences. Over the years I found a collection of hundreds of people whose stuff I really enjoyed reading. On web development, but also other interests. Some posted often, others occassionally. Either way, I learned so much from the tweets, links to other sites, discussions and what not. More people started following me too, and I managed to develop real friendships. My DMs got busier too.

There were always compelling reasons to leave, too. The platform and tweets became more engagement-focused, the Twittersphere attracted more and more grifters. The algorithmic timeline was introduced, although that could be turned off.

There was also the increasing abuse, especially towards minorities. Under Jack Dorsey's leadership, Twitter systematically failed to act on reports of racist, homophobic and misogynist accounts, making the platform more dangerous to anyone not a cis white male, even getting users in physical danger. Some of that was described in a 2018 Amnesty International report on Twitter called “A toxic place for women”, a document full of details on how the company failed to respect women's rights.

And then there was the risk of making content on a platform that you don't control. My friend Manuel got permanently suspended, for reasons unknown to him. I can only imagine what it was like for him to just lose access. A lot of us tried to change the minds of “@TwitterSupport”, but it wasn't resolved. For a lot of folks it was a wake up call to reconsider where they post. I realised my new ambition was to like, Zach, take ownership of my tweets.

Last week, I still didn't feel like leaving the platform just because the new owner was an arrogant troll with world views orthogonal to mine. I imagine this may be the case with more services I use, and had tried Mastodogn before without much success. I don't think I really believe in decentralised social networks, I would rather have all my friends in one pub than spread across pubs. But then that new owner fired Twitter's entire accessibility team and large parts of trust and safety folks working on problems that have very real life consequences (like meddling in elections, spreading of conspiracy theories, hate crimes, impersonation), he unfolded plans for a new ‘Verified’ program that made the feature for sale rather than for security and then he recklessly and cruelly fired half of the staff… so I decided to go ahead and hang out elsewhere, at least to put my content there.

That other place is ‘the Fediverse’.

the Fediverse is different: it isn’t trying to glue your eyeballs to the screen, and it’s harder for things to go viral. There is less media, fewer memes, no advertising. And there are humans explicitly in the loop: Mastodon instances are moderated on an instance-by-instance basis — and should an instance descend into a hellscape, it may find itself defederated. But because of all of this, there is also less opportunism, less trolling, less dunking on your enemies, less nastiness. So it also feels more relaxing, more earnest — and easier to put down.

(from Bryan Cantrill's Twitter, when the wall came down)

Maybe the decentralisation aspect could actually work. It's a bit like email.

It seems like the new owner and his behaviour is driving people in my bubble away from Twitter, towards the Fediverse, personal blogs, RSS and other platforms. Probably mostly in that bubble, but maybe it is a wider thing, time will have to tell.

I didn't suddenly stop caring about the people I follow on Twitter, so I will probably also stay on Twitter for the foreseable future. To catch up on tweets, to DM and to share posts like this one. But for the next while, I plan to hang around on Mastodon more.

---

Originally posted as Is this the last exodus from Twitter? on Hidde's blog.

Reply via email

I'm so happy about what Interop 2022 is doing for web compatibility in general. It made me think: what if we had something similar, but accessibility-specific, focused on compatibility between our code, assistive technologies and browsers? Excitingly, ARIA-AT pretty much has that goal.

Interop 2022 is great

In the Interop 2022 effort, all major browser vendors, browser engineers and other stakeholders agreed “to solve the top browsers compatibility issues identified by web developers” in one year. I danced a little when I saw that. I mean, they align their priorities between them and web developers get a say in what the priorities are. Excellent.

Subgrid, <dialog> and scroll-snap are tremendous features, but consistently cross-browser supported subgrid, <dialog> and scroll snap (and more) are the real deal. Because browser compatibility issues can be quite the nuisance. They make web development harder and more expensive. Web developers end up with a choice between either supporting less browsers or adding hacks and more bloated code. Either option likely trickles down to the experience of end users.

Unrecommendable web platform features

As an accessibility specialist, I spend some of my time giving advice on how to code accessible UI components. From time to time, I want to recommend a thing, but I don't, because of bugs or inconsistencies somewhere between browsers and assistive technologies.

I asked on Twitter what people's top issues were:

If you could fix 3 bugs in assistive tech or browsers, to make building accessible UI components more straightforward, what would they be?

Some responses that came in, all browser focused:

• display properties (still) break default semantics (thanks Adrian Roselli for all his work documenting the issues in detail)
• the HTML video player has keyboard accessibility, focus management and screenreader issues in various browsers (see also: Scott Vinkle's post How accessible is the HTML video player? from 2019)
• aria-controls is not or weirdly supported by screenreaders
• The expanded state of details/summary is not communicated to users of screenreaders in Firefox if the arrow is hidden (as documented by Scott O'Hara in The details and summary elements, again). That's a problem: conveying status to assistive technologies is a core feature of functionality that does visual expanding and collapsing
• aria-owns is not supported in Safari (see also: Diego Haz' demo)
• Default field validation cannot zoom

Having these issues open for so long hurts web accessibility:

• developers who aren't aware may think that by using the platform they get accessibility by default and unknowingly build something inaccessibly
• developers who are aware may end up adding all sorts of hacky code to fix the issue on their end, which could lead to maintainability issues in the long term and makes accessibility unnecessarily hard
• developers generally will have a greater chance of shipping inaccessible interfaces

On Twitter, people also replied with other interesting ways browsers could improve accessibility, like a browser implemention of “skip to <main>” (as Léonie suggested) or even to any landmark (as Curtis said).

And then there are issues around what browsers do, but (some) accessibility specialists disagree with, like that <dialog>'s focus trap can escape to the browser chrome. I've heard from developers whose accessibility consultants recommended them not to use <dialog in the first place and that's an issue.

I believe in personal responsibility when it comes to building a more accessible web. Teams need to test their work and ensure accessibility. But at the same time, change in the primitives (like browsers and CMSes) is needed and can improve a lot of accessibility at once. All of the above issues are most easily solved by browsers, not individual web developers (see also my earlier post, More accessible defaults, please).

ARIA-AT

If we look beyond just browsers and focus on assistive technologies, an interesting project comes to mind. The W3C's ARIA-AT Community Group has the goal to ensure “assistive technologies work with web code in predictable ways”. The group works on interoperability in four ways (taken from their homepage):

• write tests; they help ensure alignment between how assistive technologies behave, and with that, what users can expect
• run tests across different assistive technologies (currently focused on screenreaders, including JAWS, NVDA and VoiceOver)
• build consensus in the industry
• enable scalable automated testing (for which they are writing a standard, see the AT Driver explainer)

The ARIA-AT explainer video explains why this is so important: “there are hundreds of interpretation issues between screenreaders,” and “the way screenreaders and browsers interpret web code changes all the time”.

I am very excited for this project, it will be super cool to see the test results pop up in places like the ARIA Authoring Practices Guide.

Summing up

It would be great for the web to see browsers prioritise accessibility bugs and align between them on the accessibility aspects of current features like <dialog>, <video>, form validation and aria-controls. Either as part of the regular Interop program, or separately. At the same time, returning to the question I started with: yes, more interop between assistive technologies would be very welcome. Improving how assistive technologies interpret our code is a fantastic goal—I'm excited for the impact ARIA-AT will have.

---

Originally posted as Do we need an Interop for assistive technologies? on Hidde's blog.

Reply via email

Concepts of the web platform can sometimes be quite different, yet seem very similar. Semantics, behaviours and characteristics are different things, even if they are sometimes combined into one thing. As a new popup attribute is in the works, this post will go into the differences between dialogs, modals, overlays, popups, disclosures and full screen content. All somewhat related concepts that can seem very similar. Let's dive in!

The thing with words and concepts is that they can mean different things to different people in different places and times. The concepts in this post are no different. I noticed that browsing some older resources, like the WHATWG wiki on dialogs. For clarity, throughout this post, I will refer to the concepts of dialogs, modals and popups as they exist in standards like HTML, CSS and ARIA. The definitions here are meant to align with the relevant specifications first and foremost, and with individual team's naming conventions second.

Below, we'll start with a bunch of characteristics: things components can have, like modality, light dismiss, top layer presence and backdrops. Then we'll talk about what we get when these characteristics are used together: dialogs, popups and disclosures.

The characteristics

Light vs explicit dismiss

One major difference between these components is in how users would dismiss them and whether that is affected by other elements.

‘Light dismiss’ is the main feature that popups bring to the table, you only get it when you make an element a popup.

Modality / inertness

The web platform has this concept of content being ‘inert’: it means that you cannot interact with the content. It is only really there visually, but you can’t do anything with it.

When an element is in a modal state, it is the only thing that can be interacted rest with and the rest of the page or application should be inert. You should not be able to tab to anything outside of the modal element, or scroll in content outside of the modal.

Elements that are not modal are called non-modal or modeless.

Top layer presence

By default, if multiple elements are positioned in the same location, they are painted by the browser in layers. This is done in DOM order: the element that is first in the DOM is painted first, each subsequent element on top of the previous and the last one in the DOM is painted last, at the top. With the `z-index’ property in CSS you can deviate from the default on a case by case basis, and decide your own layer order.

The top layer is a special layer that is, as the same suggests, always on top.

Popups are in the top layer when they are of the ‘manual’ type

Dialogs are not.

Backdrop

In some cases, it makes sense for elements to have a backdrop, usually this is done when they overlay the page.

With the ::backdrop pseudo element, you can optionally add a backdrop to your popup or modal dialog. This is done when they are modal, as in that case, none of the stuff behind the element can be interacted with. A backdrop gives a visual cue for that behavior.

A backdrop obscures content behind it and is used as a visual cue that this content is unavailable, in combination with a method to actually make it unavailable (inert).

I'll say overlay is another word for an element that has a backdrop.

Trapped focus

Sometimes focus should return to the “invoking element”. A popup will return

Sometimes focus is trapped:

• traps focus if it is opened with showModal(), but not if it is opened with show() (via https://whistlr.info/2021/in-defence-of-dialog/)
• popup does not

‘Not for recreating dialog’ - Scott https://github.com/openui/open-ui/issues/415#issuecomment-1261565368

Keyboard closability

In general. things that can open would e

The main concepts

• Dialog
• Alertdialog
• Modal
• Popup
• Aria-haspopup

Dialog

The <dialog> element is something a ‘user interacts with to perform a task’ (see: dialog spec). It's often displayed when users need to choose. Do you want to continue, yes or no? If you want to open a new file, what shall we do with your current file, save or delete?

Dialogs are a lot like window.confirm() and friends, which the HTML specification lists under ‘simple dialogs’. They do offer more flexibility—you get to put whichever content and styling you want inside of them.

You can even put a form with `method="dialog"' in a dialog, which will close it when submitted.

Dialogs have a role of dialog, which the browser will assign automatically for you when you use the <dialog> element.

Dialogs can be modal (when shown with dialog.show() or non modal (when shown with dialog.showModal()).

Alert dialogs

WAI-ARIA defines a specific type of dialog, which is called “alert dialog”. It is meant for dialogs that contain brief, important message and They need to alert the user, which the browser should fire as a system alert event to accessibility APIs.

Examples

• After you didn't interact with your online banking environment for 10 minutes, and alert dialog shows and tells you you will log out in 5 minutes, unless you press “Continue my session”

Characteristics

Alert dialogs are always modal and have their focus trapped. They also require an accessible name. If there is a visible title, the title's id can be associated with the alert dialog's aria-labelledby attribute. If not, aria-label can be added to the alert dialog.

Popup

Popup is a set of behaviors that can be added to any element through the popup attribute (like tabindex or contenteditable). At the time of writing, it isn't in the HTML specification yet, but there is the Pop Up API Explainer and a PR to the HTML spec.

The popup attribute is meant for UI components that are:

• on top of other page content
• not always visible (eg just when they are relevant)
• usually displayed one at the time

An example of a popup is the listbox that shows when a select is opened (conceptually for <select> and literally for <selectmenu> as it is currently implemented in Chromium). Datepickers, teaching UI, tooltips and action menus are all examples of popup-like behaviors.

Example of a popup: Twitters alternative text feature (implementation has accessibility issues)

Popups have ‘light dismiss’ behaviour, meaning they close by themselves, except when they are of the “manual” type. Manual popups could be things like a “toast” notification that is dismissed via a timer or manual button.

Popups also can be opened, closed and toggled without JavaScript: with a <button> in HTML and popupshowtarget, popuphidetarget and popuptoggletarget attributes whose values correspond with the popup's ID, the browser can take care of showing, hiding and toggling.

An example:

<button 
  type="button" 
  popuptoggletarget="datepicker"
>Pick date</button>
<div popup id="datepicker"></div>

(the div is made a popup with the popup attribute, the button toggles the popup with popuptoggletarget)

Popups don't have a default role, . Sometimes they could be dialogs, so you would use <dialog popup>,

So, in summary: popups are a behaviour that gets added as an attribute to any element. It brings light dismiss, toggling with or without JS an

Note: Don’t confuse popup with aria-haspopup, which was deprecated in ARIA 1.2, can be a dialog, menu or other things. It requires developers to implement a focusable trigger and browsers to send an alert.

Disclosure widgets

Elements that show and hide things are often called ‘disclosure widget’, as Adrian Roselli describes in [Stop using ‘popup’]](https://adrianroselli.com/2020/05/disclosure-widgets.html). Adrian describes disclosure widgets in more detail in his aptly named post Disclosure widgets.

Disclosure widgets exist in HTML as <details>/<summary>, but can also be built with <div> and the appropriate ARIA attributes. This isn't entirely the same. In Details/summary, again, Scott O'Hara suggests that this is more consistent:

If your goal is to create an absolutely consistent disclosure widget behavior across browsers, i.e., ensuring that all `

s are exposed as expand/collapse buttons, then you’d be better off creating your own using JavaScript and the necessary ARIA attributes.

But, he adds, your ARIA disclosure widget won't have some of the features <details>/<summary> brings, like in-page search (Chromium triggers a <details>'s element open state when an in-page search query is found in its content).

• A dialog is modal when opened with dialog.showModal() and not modal when opened with dialog.show(); with popups, non modal dialogs are probably going to be obsolete (@@@)
• Full screen elements are modal when

Gotchas

Dialog node vs document mode

If you use <dialog> or role="dialog", assistive technologies will switch to application mode when the dialog is opened. This can make it so that some users can't access browse structured content in the way they are used to (eg browse byy heading or lists). For this reason, it is recommended to wrap any structured content inside of an element with role="document", like so:

<dialog>
  <div role="document"></div>
</dialog>

Source: https://github.com/twbs/bootstrap/issues/15875#issuecomment-75668416

Hidde's open questions

• is a tooltip a popup? [yes ?]
• is a cookie banner a dialog?
• chat popup

https://developer.apple.com/design/human-interface-guidelines/guidelines/overview

Summing up

---

Originally posted as A dialog, a modal and a popup walk into a bar. How are they different? on Hidde's blog.

Reply via email

Like many people, I have been monitoring the creation of WCAG 2.2, the upcoming new version of the Web Content Accessibility Guidelines. Nine new Sucess Criteria are proposed. One particularly worries me: 2.4.11: Focus Appearance.

Focus Appearance builds on two existing WCAG criteria that affect focus indicators: that users can see which element has focus (2.4.7), and that focus styles have sufficient contrast (1.4.11). Focus indication is essential for a wide range of users, including users who browse by keyboard or zoom in. For an introduction to why focus indication matters, see my post on indicating focus.

What's new about 2.4.11 is adds more requirements for what the indicator looks like:

• an element with focus needs to have sufficient contrast with its non-focused state
• an element with focus needs to have sufficient contrast with its surroundings
• the focus indicator needs to either be a solid line (so not dotted or dashed), or have a certain level or thickness (in which it can be dotted or dashed)

It's a clever new criterion, that addresses important user needs that were previously unaddressed. The Working Group clearly put a lot of research and thought into it. This is hard to do, as co-chair Alastair Campbell mentions in a GitHub issue:

what makes a visible focus indicator is not particularly straightforward

This is the crux of why this isn't trivial to solve and I appreciate everyone's efforts on the proposed Success Criterion. I know the text has had revisions and improvements after people have flagged complexity issues. Still, I'm sorry the Success Criterion as it stands now has me worried.

“Focus Appearance” is “at risk” of being removed from the final version of WCAG 2.2. My vote would be to drastically change it (again) or remove it entirely. Firstly, the requirements are complex to apply or teach. Secondly, browsers, OSes or assistive technologies could guarantee focus appearance better (and I feel it would be easier to talk to them than to convince all of the world's web developers).

Why I hesitate about including 2.4.11

Complex to apply

I expect Focus Appearance would be hard to apply, because the Success Criterion text has a lot of complexity. It is full of clauses and sub clauses. It often includes “and” (8 times), “or” (7 times) and “non”/“not” (4 times). There are two ways to meet it (you can choose one or both), and there are two exceptions and three notes. All in all, it's a lot to grasp.

The wording requires knowledge of a lot of specialised terminology, especially in the “area of the focus indicator” part. It may be that I am a non-native English speaker, but I had to look up what a “perimeter” is. The Oxford Dictionary of English states:

the continuous line forming the boundary of a closed geometrical figure

WCAG 2.2 makes this definition more specific to the web by defining “perimeter” as ”continuous line forming the boundary of a shape not including shared pixels, or the minimum bounding box, whichever is shortest”.

In this, “minimum bounding box” has its own definition:

the smallest enclosing rectangle aligned to the horizontal axis within which all the points of a shape lie

And because it is about web content, another clause is added:

For components which wrap onto multiple lines as part of a sentence or block of text (such as hypertext links), the bounding box is based on how the component would appear on a single line.

This is a lot to take in and it seems easy to misunderstand. There are so many sub definitions needed. One could easily misinterpret the concepts of a bounding box, the perimeter,“shared pixels”, “CSS pixels” (ok, that's already used in Reflow and Target Size) and apply the whole SC wrongly.

This makes 2.4.11 Focus Appearance very different from other criteria, like Non-Text Content or Keyboard. Accessibility specialists will know there are indeed lots of ways not to meet those requirements, but the general idea of how to comply is easier to grasp. Very few people will need to look up what a keyboard or text is.

Admittedly, there are easy ways to comply with the proposed Focus Appearance, too. One is to have a solid outline with a minimal offset of 1px that has sufficient contrast (3 : 1) with its background, as James Edwards explains in New Success Criteria in WCAG 2.2.

Complex to teach

As someone who sometimes teaches WCAG to teams, I also worry about the complexity of 2.4.11. I could teach the ‘easy way’ described above, that doesn't seem too complex to teach. But if I would try to teach the whole Success Criterion with all the requirements, exceptions and notes and also cover what the Understanding document explains, I fear I won't get it across.

“But teaching is your job, Hidde!”, you might say. Yes. And I could probably make it work, but it would take class time that I would like to spend on other barriers, and there is still the risk the information sticks with participants less because of the complexity. There will also be people trying to apply this Success Criterion on their own.

Leave it to browsers

We can't just leave all of our problems to browsers to fix. But if I had any say in it, browsers should fix any accessibility problems they are able to fix. That way, end users have to rely less on individual web developers to make good choices. I feel focus indication is a great example of that: the browser knows what has focus, users want to know it, web developers could fail to add a good indicator. So why rely on web developers?

In a discussion on relying on browsers for focus indication, the Working Group concluded that browsers don't do sufficient default focus indication today, so if we want accessible websites, we need to require it through WCAG. If browsers start to do it later, the requirement could be removed or moved to a different level then. A chicken and egg situation, basically, but with one of them more likely to materialise (I'm not super sure which, to be honest).

A second argument is that web designers are in a better position to design an appropriate indicator, one that fits well with the rest of the site's design. But it's unlikely those designers can take into account user needs as well as a browser could with settings. Some users may prefer an indicator they can see move from one element to another, some may want a very high contrast indicator, some may want it more subtle (see also Rain's comment mentioning high visible focus indicator from a COGA perspective). A browser could provide options. We wouldn't want individual websites to start offering focus indication choosers, right?

Forced focus indication already exists in various forms through OS settings, assistive technologies (like VoiceOver) and even some (buried away) browser settings (in Chrome). There is a bunch of browser plugins and bookmarklets that force focus indication, too. So we've got forced visibility. Forced “good appearance”, however, is not fully in browsers and harder to implement, of course. It would need to account for all the things 2.4.11 requires, like sufficient contrast with surroundings (the browser/add-on/plugin would need to make it work with any background) and sufficient contrast with non-focused state.

I get the idea of putting this on developers before full browser support exists, but it does feel a bit like solving all problems with one (conformance-shaped) hammer. It also doesn't apply when developers simply don't meet WCAG. Yes, there are human rights, ethics and laws, but we know they are violated a lot today. I fear this will only be more common when the requirements are too complex.

How to make it less complex

I know WCAG 2.2 is close to its last standardisation stages, so I'm sorry to bring this up now. I also don't want to just say ‘don't include 2.4.11’. Let me describe a possible way to make the situation less complex for developers, evaluators and teachers, by replacing Focus Appearance with multiple Success Criteria:

• Focus Distance to require a minimum offset between the focused element and its outline
• Focus Solid to require solid, unless a minimum thickness is used

These two on their own seem a lot less complex to apply, test and teach. As minimum contrast and visibility are already covered in other Success Criteria, these two criteria between them would make focus indication much better for low vision users, while not adding the complexity 2.4.11 adds.

Conclusion

The proposed Focus Appearance criterion does a great job at capturing which problems end users have around focus into requirements. But it lacks understandability for users of the standard: people who make websites, people who evaluate accessibility conformance, developers of testing tools, et cetera.

It may seem reasonable to say those understandability concerns are secondary to the ability of end users to use the web. Of course they are. But if there is too much complexity in WCAG wording and mathematics, I worry the web won't actually get better for end users. We'll lose the people who need follow the recommendations. This is already an issue with current requirements, as shown by the many “WCAG in plain words” derivatives and checklists that exist. The original source gets plenty of “appropriate requirements love”, it could use content design love.

I'm sorry, but I feel WCAG 2.2 is better off without 2.4.11. Even after some iterations, it (still) adds more complexity than we should want WCAG to have. It's difficult to apply and teach. It may end up like Terms and Conditions: factually correct, but commonly skipped over. That would be problematic in this case, and mean not considering important end user needs.

My ideal resolution would be (I know, easier said than done): sit down with browser makers and improve the focus indication game structurally together. Meanwhile, people who make websites can prioritise the 86 other WCAG Sucess Criteria (rather than implementing 2.4.11 until browsers are ready). Focus indicators are a core need web users have, it needs better appearance and likely choice in appearance, let's bring the research from AGWG into (browser) practice.

---

Originally posted as 2.4.11 Focus Appearance adds more complexity to WCAG than we should want on Hidde's blog.

Reply via email