Chris Ashton

fortnight11y issue 49

Your fortnightly frequent11y newsletter, brought to you by @ChrisBAshton:

Accessibility inception: sharing your knowledge (video, 46m)

  • This is a Mischa Andrews talk from #ID24 in November 2017. I’ve had it in my bookmarks for a while, and am so pleased I’ve finally managed to watch it.
  • Mischa talks openly and candidly about how you can effect accessibility change in your organisation, whilst overcoming the inevitable office politics that come with the territory.
  • I liked the idea of creating a “decoy audience”. Let’s say you have a colleague who feels they have nothing to learn about accessibility – they “know it all already” – but they consistently make accessibility mistakes. You can teach them how to do things properly, without bruising their ego, by arranging a talk or workshop about accessibility, and inviting them to present part of it. The theory is that they can continue to feel good about their own knowledge, whilst also opening up to learning from your side of the talk.
  • A common tactic used by organisations is to have a ‘gatekeeper’ for accessibility, e.g. someone doing accessibility testing as part of the acceptance tests at the end of a project. Mischa warns that you have to tread carefully here, as it’s often too late or difficult to do much about accessibility issues if they’re left until the end of the process. You may also find people try to work around you, such as go to your manager or try to argue that their project shouldn’t go through the normal process. It is best to only use this ‘gatekeeper’ tactic if your organisation is already practising good accessibility.
  • Make it as easy as possible to do the right thing, e.g. by adding accessibility information directly as code comments, or embedded in Word templates, rather than expecting people to seek out and find the guidance independently.
  • Practice what you preach. You may be seen as the a11y expert in the organisation, and people will reuse your resources, such as colour choices, etc, on the assumption that they’ve already been accessibility tested.
  • It is useful to memorise a handful of things that can be used as opportunities to motivate people – and to convince people to listen to you. If you know statistics around how many people have particular kinds of disabilities, or how much money the organisation loses through being inaccessible, or what accessibility laws your country has to abide by, or the difference between different versions of WCAG, you’ll look knowledgeable enough for your words to carry more weight. You can also slip these facts into conversations, which can help to inspire the next generation of accessibility advocates in your organisation.

Next is a two-article special, covering accessibility advances by Android and Apple!

Google Improving Smartphone Accessibility

  • Two new features are coming to Android smartphones: “Camera Switches“, and “Project Activate”. These features will allow users to use gestures like smiling, raising eyebrows, or looking in a particular direction, to issue a command such as returning to the homescreen or opening notifications.
  • The gestures are configurable: users can set how long to hold the gesture for, or how big the gesture must be, to issue the command.
  • “The updates are aimed at people with motor and speech disabilities, Google said, and the new tools were developed with feedback from people who rely on alternative communication technology.”

Apple is testing AirPods as possible hearing aids, posture improvers and in-ear thermometers

  • Apple is prototyping to see motion sensors inside AirPods can be used to tell users if they’re slouching. They’re also experimenting with measuring core body temperature, and perhaps most excitingly, whether or not AirPods can be used as “proper hearing aids” (they already come with a ‘conversation boost‘ feature).
  • Under US federal law, devices marketed as hearing aids must “be sold through licensed specialists, who adjust them to the specific user”. However, “in July, President Biden signed an executive order directing the Department of Health and Human Services to allow hearing aids to be sold over the counter and be adjusted by consumers”; promising news for Apple.

Buttons vs. Links

  • Eric Eggert describes the difference between a link and a button:
    • A link changes what the URL in the browser points to; either a new page, or a file to download, or a frame to update the source of.
    • A button performs an action. Originally only available as an <input type="submit" />, with the sole purpose of submitting forms, then along came the <button> element which allowed more versatility. It’s great for creating things like calculators, where the end result URL is not an important thing to be able to share.
  • Links and buttons have different roles. Assistive technologies announce them as “link” and “button” respectively, and this sets a user expectation as to the behaviour.
  • Screen readers have a way of easily presenting all the links in the page; buttons are harder to surface.
  • Links can be activated with the return key, whereas buttons can be activated with return or space.
  • Context is important. You can style a link to look like a button, and that’s fine, if the button says something like “Read the full story”, which hints that it will take you to another page.
  • Eric concludes that the link vs button debate is a grey area. He’s surprisingly unopinionated in the close: “there is no one true way to code or design something”.

As a bonus for the above article, I also read THE BUTTON CHEAT SHEET ( It compares different ways of marking up buttons and button-like things. I don’t really see how useful it can be, but it’s worth a quick look through, if only to see how many different ways it can be done.

Three Olay jars of cream, in different colours, each topped with a white easy-open lid.

Olay Designs An Easy-Open Lid—& Shares the Inclusive Design

  • Olay, the beauty products manufacturer, have designed a new lid prototype for its creams, designed to be accessible.
  • It has an “easy open winged cap”, “extra grip raised lid”, “high contrast product label”, and Braille text spelling out “face cream”.
  • The lids are currently only available on Olay’s website.
  • The design is open-source, meaning other beauty brands are free to use it and build upon it.

Gorillas’ nav: a case study

  • A really interesting article by developer & accessibility advocate Kitty Giraudel, explaining how they built the main navigation on their employer’s website, Gorillas.
  • It’s a hamburger menu style across all screen sizes, not just on mobile. You have to tap on the ‘hamburger’ to expand the menu and show the menu items.
  • This behaviour comes for free with the <details>/<summary> HTML elements, which as native elements, work without JavaScript. However, clicking outside of the menu should cause the menu to ‘close’ again, and that doesn’t happen with those elements, so Kitty & the team replace the elements with a <button> if JavaScript is available, adding a listener to the click and focusin events to close the menu if the event takes place outside of the menu container.
  • “Landmarks such as <nav> can be listed by assistive technologies, [therefore] it’s important that the <nav> itself is not the element whose visibility is being toggled. Otherwise, it’s undiscoverable when hidden”. So Kitty’s implementation wraps the menu in a <nav role="navigation"> and the CSS visibility toggling is only applied to its contents, not to the <nav> element itself.
  • Kitty walks through a good example of progressive enhancement in CSS, using the @supports query to check if backdrop-filter is supported before overriding the background-color.
  • Elsewhere on the Gorillas page, there is a language selector. Kitty points out that they avoided using flags to denote language, as flags are ultimately for countries, not languages (think UK vs USA flags for English).
  • The language selector uses 2-letter codes, e.g. “EN” for “English”, with visually hidden text to clarify the language name: <a href="/en" hreflang="en">EN<span class="sr-only" lang="en"> — English</span></a>. Note the hreflang attribute, which I hadn’t heard of before, but is supposed to indicate the language of the page that is being linked to. Kitty admits it “might do nothing”, given the lack of documentation on it.
  • They initially tried applying an aria-hidden to the 2-letter language codes to avoid assistive technologies reading them out (as they’re often incorrect, e.g. “DE” being pronounced “duh”). However, this would fail WCAG SC 2.5.3 Label in name, as voice navigation users should be able to navigate the page by what they see, e.g. “click DE”.
  • Finally, I’ve learned that “When using aria-expanded="true", the label should not mention “open” or “close” (or similar) as the state is already conveyed via the attribute”.

Vicky Teinaki shares this tip on Twitter: “I was today years old when I found out that I can share a Google Slides presentation in html (for screen reader users and magnification users) by swapping out ‘/edit’ in the URL for ‘/htmlpresent’.”

Share presentation in html (for screen reader users and magnification users):[link censored]/htmlpresent
Screenshot of a Google Slides URL, ending in “/htmlpresent”.

National Convention Sponsorship Statement Regarding accessiBe

  • The (American) National Federation of the Blind made a statement in June, about accessiBe, the market leading ‘accessibility overlay’ company that I’ve written about several times now.
  • I missed this when it came out, and wouldn’t have known about it were it not for Steve Faulkner’s tweet. He picks out this pretty damning quote:
  • “This week, the Board of Directors reviewed accessiBe’s business practices at the urging of members who have researched and interacted with the company, and the Board believes that accessiBe currently engages in behavior that is harmful to the advancement of blind people in society”.
  • The statement goes on to announce that the NFB has “revoked accessiBe’s sponsorship of the convention”.

Did you know that you can subscribe to dai11y, week11y, fortnight11y or month11y updates! Every newsletter gets the same content; it is your choice to have short, regular emails or longer, less frequent ones. Curated with ♥ by developer @ChrisBAshton.