Welcome to your monthly frequent11y newsletter, brought to you by @ChrisBAshton. I hope you enjoy these a11y articles I’ve collated and summarised for you. (Psst – if you find these emails too long, consider switching to shorter, more frequent updates). Now on with the show!

Sony’s new Back Button Attachment brings customizable paddles to the DualShock 4

• Sony are releasing a $30 attachment for the DualShock 4 controller which slots into the back and provides two extra large buttons. These can be mapped to any of the other buttons on the controller, and could be a (literal) game changer for disabled users who may struggle to use the controller standalone. It’s not being marketed as an accessibility aid, but as a tool for power users to level up their gameplay. Indeed, non-disabled users could find the tactile buttons improve their gaming performance.
• Aside: It’s highly unusual for Sony to release something like this so late in the PS4 lifecycle, which suggests these might work with the DualShock 5 when it comes out.

Epilepsy Foundation Bombarded with Seizure-Triggering Twitter Posts

• The Epilepsy Foundation has filed a criminal complaint with the U.S. Attorney and the Office of the State’s Attorney in Maryland, against a number of Twitter uses who maliciously posted seizure-inducing content on its feed. This happened during November: National Epilepsy Awareness month. A similar attack happened in 2016 against journalist Kurt Eichenwald, which purportedly triggered a seizure.
• Aside: around 3% of people with epilepsy can be triggered by exposure to flashing lights or certain visual patterns.

Accessibility Testing by People with Disabilities

• An article of two halves, by a11y expert Becky Gibson. The first half gives guidance for performing your own a11y audit. It recommends WAVE as a starting point, followed by the Web Developer extension for validating document structure and numerous bookmarklets for additional automated tests. This is followed by manual keyboard and screen reader testing – checking for WCAG 2.1 AA violations (as opposed to WCAG 2.0, which was released in 2008 and has little guidance for mobile) – and finally, testing responsive design and zoom/magnification. The second half highlights Vision Aid for specialising in training blind individuals as testers, and argues the business case for this (‘native’ screen reader users will spot problems more quickly and catch some issues that other testers might not).

What to Do If You Think Your Child Is Color Blind

• Around 1 in 10 males have some form of colour blindness – a much higher rate than that in women. It’s a genetic trait typically passed down from the mother. You can conduct Ishihara tests at home (online) to determine colour blindness. There is no cure but there are ways you can manage the condition, e.g. by labeling things rather than relying on colour alone.

Mattel releases first deck of UNO in Braille

• The first official braille UNO deck is going to the Idaho School for the Deaf and the Blind. Some students have played it before but have needed to have teachers adapt existing sets by hand braille-ing them. The braille deck looks identical to the non-braille deck, but has some non-intrusive dots in the corner of each card. It makes you question why games companies don’t make their products braille-friendly by default.

‘No captions no vote’: why deaf voters are calling for more accessible campaigning this general election

• Article by Liam O’Dell, highlighting that a lot of political campaign videos lack captions, making them inaccessible to the 11 million people in the UK (1/6 of the population) with deafness or hearing loss (not to mention that 85% of all videos on Facebook are watched without the sound on). This has triggered the #NoCaptionsNoVote campaign, where deaf people threaten not to vote for parties who don’t provide captions. Liam draws attention to the closure of the Access to Elected Office Fund, which affects deaf candidates standing to become MPs, who now have to fund their own costs such as interpreters. Finally, some but not all parties have published their policies in British Sign Language.
• Bonus article: read How Philly is making all voting locations accessible for the first time ever (November 5th 2019). TDLR: all venues have been ‘accidentally’ made wheelchair accessible so that there was enough room for workers to erect the new (large) touchscreen voting machines.

Screen reader bug fixed in Firefox

• In September 2018, GDS Accessibility Expert Anika Henke filed a bug report with Mozilla, suggesting that words are incorrectly merged together in screen readers when using word-wrap: break-word with a small width. For example, “posted on” is pronounced “postedon” if its container is so small that each letter is on its own line. The root cause was actually a 4 year old bug to do with trimming whitespace, which Firefox has fixed in its latest version (Firefox 71). You may be interested in alphagov/reported-bugs to see all bugs GDS has reported in browsers, operating systems and assistive tech. Meanwhile, well done all who take the time to report, debug and fix these far-reaching issues!

Playing with state

• Article by Sarah Higley, exploring how best to denote the state of a Play/Pause video button for screen reader users. Most ‘toggle buttons’ for a binary state should have an aria-pressed attribute with value “on” or “off”; screen readers communicate this ‘state change’ more quickly than a change in property (such as aria-label). Sarah argues that the play/pause button, however, is the exception to the rule and should only change the aria-label (from “Play” to “Pause”), as changes in state don’t make sense in this context (“play button off”). Most importantly, avoid changing both or you’ll confuse your users (“play button, on” vs “pause button, off”).

When Things Go Wrong for Blind Users on Facebook, They Go Really Wrong

• An article highlighting the regularity of bugs and missing features encountered by screen reader users on the Facebook apps and site, with a strong message that there is an under-investment in accessibility development on Facebook and Instagram. A feature for adding colourful backgrounds to posts meant all posts were read out as “Awesome Text Status” for a week. Facebook’s attempt at automating alt text has met a muted response; “image may contain child” doesn’t allow screen reader users to participate. There are options to provide alt text on uploaded images, and forms for flagging accessibility issues, but both are criticised as being too hard to find. Some users have created Facebook groups to share images of text they want transcribing by sighted volunteers. There’s something to be said about the ‘move fast and break things’ ethos and what that means for disabled users.

If it has audio, now it can have captions

• Google have created functionality for the Pixel 4 phone, which they’ve dubbed Live Caption. Like the auto caption feature on YouTube videos, this overlays text on your phone screen – when enabled – showing Google’s interpretation of the audio. The text overlay can be moved independently as demonstrated in this gif, and the captioning works independently of the audio source, so you can watch any video or audio in your browser or apps and be able to get captions. It works entirely locally, so doesn’t use any cell data and stays private on your phone. Google are hoping to roll this out to other Android manufacturers “in the coming year”.

Creating Online Environments That Work Well For Older Users

• An opinion piece by Barry Rueger, who for context is “well past sixty”. He makes several suggestions that are widely recognised as universally good practices, such as improving website load speed and ensuring good grammar and spelling. Others are more subjective: that older people prefer text and ignore videos in search results, or that they hold onto old, slow machines for longer. Barry makes the case for black text on white backgrounds; a controversial subject as several user groups find this harder to read (there are some comments below the article to that effect). Finally, an interesting point about the success of Amazon being down to its website’s consistency; “we know the site, and we know that we can do our shopping quickly and painlessly”. He suggests resisting the urge to reinvent your website unnecessarily.

Accessibility drives aesthetics

• A recent article by UX designer, Alex Chen. It debunks the myth that accessible designs have to be ugly designs, giving real-world examples of websites (GOV.UK gets a mention here) and products (RX protein bar packaging) that are both accessible and aesthetically pleasing. That aside, Alex asserts that the two are not of equal importance; an interface change may not look quite as visually pleasing to one person, but another person is now able to use it. Some people concentrate their efforts on the ‘normal’ use case, neglecting designing the ‘edge cases’ for disabled people, but that is an ableist practice; “edge cases [should] refer to scenarios, not humans”. There’s a final point about disabilities disproportionately affecting people of a certain race or class, and that we have an opportunity to start to level the playing field for all.

We Analyzed 10,000,000 Pages and Here’s Where Most Fail with ADA and WCAG 2.1 Compliance

• Article by accessiBe, analysing mostly small US websites. They used automated tooling with AI to avoid false positives, e.g. avoid failing a non-compliant form if it’s never actually in view. 98% of sites failed WCAG 2.1 AA compliance with their menus alone (there are quite stringent requirements around using ESC and arrow keys to navigate the menu, which requires JavaScript rather than just good HTML markup). The next big fail was popups (89%), where most have no accessibility built in whatsoever, breaking the experience for keyboard users. 83% failed on buttons, mostly for not using <button> or role="button" markup. 76% failed on icons (often social media icons with no off-screen text). 71% failed on forms; most that passed were from ready-made systems such as Shopify.
• Aside: I chose this article to coincide with the International Day of People with Disabilities. This is an occasion “to educate the public on issues of concern, to mobilize political will and resources to address global problems, and to celebrate and reinforce achievements of humanity.” It’s also a good opportunity to remind teams in the UK public sector of their responsibility to make sites conform to WCAG 2.1 by September 2020.

Walking On Egg Shells: Why Bosses Are Scared To Talk About Neurodiversity

• Article by psychologist Dr Nancy Doyle, highlighting that companies are increasingly attempting to improve their inclusivity, but are nervous about using the wrong language. “People with disabilities” vs “disabled people” represent two different models – the first being ‘people-first’ (we are people, not conditions) and the latter being the ‘social model’ (we are disabled by a non-inclusive society). Nancy advises following a consensus where there is one: for example, the term “autistic person” is commonly used as they see it as their identity, not something they have. Where there there isn’t a consensus, we should use multiple terms interchangeably, ideally with a brief explanatory footnote at the end of written communication so that people can see that you have thought about your choices.

18 WAI-ARIA attributes that every web developer should know

• Use aria-label when you can’t use generic <label>, and aria-describedby for supplementary info, such as to associate error messages with their corresponding inputs. Use role="heading" and aria-level="2" instead of <h2> if you can’t use the element (for SEO reasons, etc). Whenever there is a visible status message on the page, it must be announced to users, e.g. with role="status" or role="alert". Use role="search" for landmarking a region responsible for search – there is no HTML5 element for it.
• Aside: this article links to the incredibly useful aria practices document, which shows recommended implementations for common components like breadcrumbs and carousels.

Making a Better Custom Select Element

• A ‘how-to’ guide from accessibility expert Julie Grundy. It describes the drawbacks of the native <select> element – the lack of autocomplete, the inflexibility around what can appear inside each <option>. Julie talks us through building a custom select, avoiding the accessibility pitfalls that many custom select components fall down at. She starts from a baseline of <input type="text">, with progressive enhancement layered on to turn it into an autocomplete dropdown with keyboard functionality and total screen reader support. It links off to the ARIA 1.1 Combobox with Listbox Popup Example, which is also a good dev resource for this.

The Physics (and Economics, and Politics) of Wheelchairs on Planes

• A detailed article highlighting the stress of flying as a wheelchair-user, involving being picked up and strapped into an ill-fitting seat while your wheelchair is put in the hold (and subsequently lost or damaged in transit, as happens in a lot of cases). The principle reason cited is one of safety, but a lot of research has been done to show that wheelchair tests are actually more stringent and can withstand more G-force than the airline seats themselves. A new aircraft design is proposed where wheelchairs can be securely fastened into the floor, or an airline seat fitted at the last minute if there are no wheelchair-using passengers. It could be two years before the American Transportation Research Board releases its initial findings to “the feasibility of the restraint system”, bearing in mind the myriad of different wheelchair types and sizes. The final fight would be persuading each airline to adapt and get on board.

Whew, that was a long newsletter! Did you know that you can subscribe to smaller, more frequent updates? The dai11y, week11y and fortnight11y newsletters get exactly the same content. The choice is entirely up to you! Curated with ♥ by developer @ChrisBAshton.