Amanda Rush

Dear accessibility practitioners, please don’t use @medium as your primary publishing platform. Syndicate there if you must, but Medium doesn’t support alt text for images, and has given no indication that it plans to. Its last comment on the subject of alt text was made several years ago and amounts to “Sorry not sorry”. So, avoid Medium as your primary publishing platform, and go with a website of your own that you can control instead. Then, syndicate to Medium.
Read The boring front-end developer by Adam Silver (Adamsilver.io)
Cool front-end developers are always pushing the envelope, jumping out of their seat to use the latest and greatest and shiniest of UI frameworks and libraries. However, there is another kind of front-end developer, the boring front-end developer. Here is an ode to the boring front-end developer, BFED if you will.
I’m not saying that a framework or design style is automatically rendered inaccessible simply by virtue of its becoming trendy. It’s worth pointing out though that, if there were less emphasis on using the hottest thing and more on all the very unsexy parts of front-end development, (semantic HTML, properly written CSS, designing with things like color contrast in mind), the web would be a lot less problematic from an inclusive design standpoint.
Demand letters are the single most ineffective tool for creating meaningful improvements with regard to web accessibility, and are the quickest way to torpido the cultural and policy changes which allow technical fixes to be anything more than temporary, surface-level progress. Demand letters serve only to turn accessibility advocates into ambulance chasers. This is a hill I will absolutely die on and anyone who disagrees with me is more than welcome to bring it on.
Read WordPress 5.2: Mitigating Supply-Chain Attacks Against 33% of the Internet by Scott Arciszewski
WordPress 3.7 was released on October 24, 2013 and introduced an automatic update mechanism to ensure security fixes would be automatically deployed on all WordPress sites, in an effort to prevent recently-patched vulnerabilities from being massively exploited in the wild. This is widely regarded by security experts as a good idea. However, the WordPress automatic update feature had one glaring Achilles' heel: If a criminal or nation state were to hack into the WordPress update server, they could trigger a fake automatic update to infect WordPress sites with malware. This isn't just a theoretical concern, it could have happened if not for WordFence's security researchers finding and disclosing an easy attack vector into their infrastructure. WordPress 5.2 was released on May 7, 2019 and provides the first real layer of defense against a compromised update infrastructures: offline digital signatures.
Everybody is swooning over Google’s upcoming automated captions, except zero of the people who actually need them. I have to wondere how it is that as an industry we manage to convince ourselves that we’ve collaborated with people with disabilities on all this amazing new accessibility tech that helps us avoid the obvious solution: Do it right in the first place. I’m sure there were messages across email lists, or surveys, or whatever, with asks for testers, ETC. But the deaf community has been saying for years that automated captions aren’t an optimal solution, and it seems arrogant to me at worst and well-meaningly naive at best that all that advice about automated captions would be ignored for the sake of Google’s business goals. We know what accessibility advancements look like, because people with disabilities have been telling us what they need, for years. Maybe one day as an industry we’ll actually start listening. I’m not holding my breath for the foreseeable future though.
Read Who Do You Sue? State and Platform Hybrid Power Over Online Speech by an author (Scribd)
This essay closely examines the effect on free-expression rights when platforms such as Facebook or YouTube silence their users’ speech. The first part describes the often messy blend of government and private power behind many content removals, and discusses how the combination undermines users’ rights to challenge state action. The second part explores the legal minefield for users—or potentially, legislators—claiming a right to speak on major platforms. The essay contends that questions of state and private power are deeply intertwined. To understand and protect internet users’ rights, we must understand and engage with both.
This essay from the Hoover Institute is worth a read for anyone discussing either online speech in general or the embarrassingly wrong pieces on Sec. 230 which have appeared in both Vox and the Washington Post in the last few days. Click here to read the full version in as accessible a format as possible without having to download the document yourself and tag it.
Read ‘Work with Facebook or die’: Mark Zuckerberg by DARREN DAVIDSON
A senior Facebook executive has privately admitted Mark Zuckerberg “doesn’t care” about publishers and warned that if they did not work with the social media giant, “I’ll be holding your hands with your dying business like in a ­hospice”. In extraordinary comments, Campbell Brown, Facebook’s global head of news partnerships, indicated to publishers and broad­casters in a four-hour meeting last week that despite Mr Zuckerberg’s view, she would help publishers build sustainable business models through Facebook.
This doesn’t just apply to news organizations. Anyone who publishes to Facebook is deemed a publisher by them. And anyone who has worked in the accessibility space for two seconds knows that if you don’t have stakeholder buy-in, efforts to remedy a situation like this are doomed to fail. So don’t hold your breath on Facebook’s global head of news partnerships being able to hault Zuck’s advancements toward publishing dominance.
Read Gab is forking Brave, and Brave is forking furious by Guillermo Jimenez (Decrypt)
Gab is creating its own web browser using Brave’s open-source code, scrapping the BAT token, and replacing it with Bitcoin Lightning Network integration.

Torba says he doesn’t understand the controversy: “The entire point of open source is to allow others to build upon an existing codebase and add more value,” he says, adding that Brave itself “is a fork of the Google Chromium project,” from which it benefited greatly.
“Open-source projects are forked all the time, GitHub even shows the fork count on every repo and the community uses it as a badge of honor. I can’t imagine any legitimate reason why Brendan or anyone else would have a problem with this.”

He forgot the part about how nazism doesn’t add value.

Read It's Time to Retire "RTFM" by April Wensel
The culture of programmers and other technologists is plagued by toxic elitism. One of the manifestations of this elitism is an unrelenting hostility toward so-called “non-technical” people (a distinction that’s also ready for retirement), beginners, and ultimately anyone asking for help. If you’re unconvinced, please spend a few minutes browsing the popular¹ question-and-answer site, Stack Overflow² (just make sure you prepare yourself emotionally beforehand).
I completely agree with the author of this post that there is definitely a lot of hostility toward beginners in the tech community. However, there are absolutely times when RTFM is not only appropriate, but necessary. Take, for example, developers and accessibility, specifically semantic markup. At a certain point, developers should be taking on the responsibility of learning how to write code that runs in browsers which adheres to web standards. Another example: It’s not the job of accessibility practitioners to fix the resultant problems when standards-compliant code isn’t deployed, and it’s not our job to whip up complex yet accessible components to submit as pull requests for every open source project on the internet. At some point, developeres need to learn to do their jobs, and sometimes RTFM is the only way to get that point across. You literally cannot make things accessible without being able to consult documentation on the subject, especially when you’re starting out. You must learn how to research so you can get to a point where you can ask the appropriate questions and then work on implementing a solution. RTFM or similar isn’t appropriate when someone indicates they’ve tried to find the answer on their own and they are stuck. It’s not appropriate on the first day of class. But to say that we should throw it out completely ignores the reality that for things like accessibility or learning a programming language, reading the documentation is a necessary component of that process. It ignores the reality that, in cases where people with disabilities are asked to do the heavy lifting, (accessibility work, for example), there’s a very likely possibility that people with disabilities, who already have to deal with the consequences of developers and designers breaking things, are then tasked with ensuring that they are fixed, by spoonfeeding if necessary, and very often, for free. That is very tiring work, and there comes a point where asking people with disabilities to be compassionate to designers and developers becomes an effort that does not produce results, wastes time and energy, and creates situations where all that work will have to be done, again.
Read Avoid Emoji as Class Names by Adrian Roselli (Adrian Roselli)
The title of this post is not broad enough. Avoid emoji as any identifier, whether as strings in your script, IDs on your elements, classes for your CSS, and so on. As soon as you start using emoji, you are blocking some users from being able to understand or use your code. It doesn’t matter how popular the technique becomes (or doesn’t).
As a screen reader user, I agree with this advice, but mostly because Jaws for Windows, (“the best-in-class screen reader), pretty much sucks at any language that isn’t written with Latin characters. And quite frankly it’s time for this situation to change. In order to read Hebrew using Jaws, I’d have to call to have a flag added to my serial number to allow for Hebrew and Arabic. I don’t have to do that with my operating system, and I can handle switching my database over so that WordPress will handle actual unicode, which is necessary for expressing anything in any language which is not composed of Latin characters, but when it comes to a screen reader for which I must maintain a license, I essentially have to ask for someone else to handle this for me. That’s crap.

If you want to read or type in Hebrew or any other non-western language on a notetaker, be prepared to turn off your speech and essentially trick the braille display if it exists into accepting Hebrew braille. Turn off the speech because otherwise you can’t think in Hebrew while typing since every notetaker embeds Eloquence, and Eloquence absolutely does not speak Hebrew. Want to interact with Hebrew text on your phone and get braille feedback? Hahahahahahahaha no because even if VoiceOver and Talkback support Hebrew, (VO supports Hebrew and will smoothly transition between it and other languages), braille displays don’t. And braille displays absolutely do not support unicode to any extent.

More broadly, regarding non-western languages and code, I don’t think we should continue to ask developers who are not native English speakers and who also do not speak a language which is expressed in Latin characters to make sure their English is good enough so they can code. That seems like an all too arbitrary requirement to me. So it’s not that I’m disagreeing with Adrian, because he’s acknowledging the reality on the ground, and practically speaking his advice is what we need to follow. I just think the whole situation of coding in general and assistive technology in particular being as incredibly ethnocentric as they are is pathetically stupid.

Read A Technical and Cultural Assessment of the Mueller Report PDF by The PDF Association (PDF Association)
What can we learn about the Mueller Report from the PDF file released by the Department of Justice on April 18, 2019? This article offers two things: a brief, high-level technical assessment of the document, and a discussion on why everyone assumes it would be delivered as a PDF file – and would have been shocked otherwise.
Some interesting analysis on the technical side of the actual file, not the report itself. Thus endeth the only comments I’ll make publicly on the report or its fall-out.
screenshot of my just-updated iPhone 5S, general/accessibility/VoiceOver/Web screen, with the accessibility events feature not yet toggled to the off position

Apple is now apparently saying that its Accessibility Events feature, (you know, the one that “may reveal whether an assistive technology is active on your iPhone”), is not enabled by default. Like hell it’s not enabled by default. It sure was enabled when I installed the iOS 12.2 update last weekend on my iPhone 8+). I specifically went in to general/accessibility/VoiceOver to check, and had to turn the feature off. This note includes a screenshot of my just-updated iPhone 5S, and as sure as the sun is shining, the accessibility events feature was turned on. I have a severe allergy to BS, and Apple doesn’t get to bypass the BSometer just because it has a history of caring a lot about accessibility. Websites should be designed and developed from the beginning with accessibility in mind. The guidelines are already out there and have been out there and freely available, complete with extensive documentation so that they can be understood, for over twenty years. There’s a metric ton of freely available information from the accessibility community of practice on every aspect of those guidelines, all over the internet, for basically as long as the guidelines themselves have existed. Assistive technology tracking has been covered already by this community of practice, and we’re probably all tired of it. For Apple to lie about something as simple as whether the feature is on by default indicates at least some corporate squeamishness around implementing it in the first place, and the best thing they could do at this point is to remove it.

Read Nothing Fails Like Success by Jeffrey Zeldman (A List Apart)
On an individual and small collective basis, the IndieWeb already works. But does an IndieWeb approach scale to the general public? If it doesn’t scale yet, can we, who envision and design and build, create a new generation of tools that will help give birth to a flourishing, independent web? One that is as accessible to ordinary internet users as Twitter and Facebook and Instagram?
#Let’sFixThis To tell the truth, I don’t have an answer to the questions raised by Jeffrey Zeldman in Nothing Fails Like Success, but as someone who participates in the IndieWeb, and who has seen nothing but benefit from it, both personally and professionally, I have to hope that we can fix what we’ve broken. Not only that, I think we have to fix it, both because this is the only web we have, and because, really, we’re the ones who convinced the general public to use things like Twitter and Facebook and the like. We turned them onto these things, it wasn’t just marketers. I’m not suggesting that any of us should succumb to paralyzing guilt over any of this, and that includes Zuckerberg. For one thing, it’s a whole lot easier to see what’s wrong in the rear-view mirror than it is through the windshield, and for another, paralyzing built would prevent us from doing the fixing. We need to be clear-eyed when it comes to what we’re fixing, and in my opinion there’s a hell of a lot of things that need fixing.

If we have any hope of repair, I think we as designers and developers need to start with ourselves and our industry. We need to get our act together and start behaving like we’re a profession, and we need to discontinue the pervasive practice of rewarding all the wrong things. Those are just for starters, and they’re large undertakings in themselves. And once we get our own house in order, we’ll need to spend some time doing some seriously hard work convincing the genereal public that the content we convinced them to start putting in the hands of the big social media networks is in fact valuable enough to own and control. Next comes making it easier to own and control. Despite every word of criticism I’ve leveled against WordPress’s new editor, I believe Matt Mullenweg is on the right track, at least as far as the concept goes, because I believe the new editor will make it easier for the average, non-technical person to own and control their content, and at the end of the day, average non-technical people are the majority, not designers and developers.

I have to hope we can accomplish all these tasks. Otherewise, the only thing left is to burn everything to the ground. I hate to think we might be at that point. I’m still optimistic about the web, about its openness and independence, about it’s fundamental accessibility, and I’m optimistic about fixing it and making it easier for everyone to participate in the web. To that end, I hope to have at least a small part in fixing it.

Read The “Developer Experience” Bait-and-Switch by Alex Russell (Infrequently Noted)
We cannot continue to use as much JavaScript as is now “normal” and expect the web to flourish. At the same time, most developers experience no constraint on their use of JS…until it’s too late. “JS neutral” (or negative) tools are here, but we’re stuck in a rhetorical rut. We need to reset our conversation about “developer experience” to factor in the asymmetric cost of JS.

From Inside Higher Ed:

Both MIT and Harvard have argued in court filings that they should not be required to provide closed captions for every video they create or host on their websites. After the institutions’ first attempt to dismiss the cases was denied, there was a yearlong attempt to reach a settlement out of court. When that attempt failed, the universities again moved to dismiss the cases.
Judge Katherine A. Robertson of the U.S. District Court of Massachusetts largely rejected the universities’ second attempt to dismiss the cases. On March 28, Robertson denied the institutions’ pleas for the exclusion of their websites from Title III of the Americans With Disabilities Act and Section 504 of the Rehabilitation Act. Title III of the ADA prohibits disability discrimination by “places of public accommodation.” Section 504 of the Rehabilitation Act prohibits discrimination on the basis of disability in programs that receive federal funding.

My eyes are stuck in the rolled position, and this time I think it’s permanent. I may be missing something, but the only exception for captions in WCAG SC 1.2.2 or its “Understanding” documentation is for content which is a transcript of the video or audio. I’m not deaf, and I’m getting tired of the excuses for lack of captions or transcriptions. How many times does some variation of “it’s not popular enough” or “I can’t afford it” or “it’s too hard” have to be tossed out? People and organizations will spend hundreds or even thousands of dollars on audio or video equipment, only to then not caption or transcribe the content they create. And Harvard and MIT both are schools which could afford to transcribe their content, so hearing from them that they care about accessibility as long as it means they don’t have to caption all of their content is especially galling. I suppose if we’re talking about a podcast that’s just starting out, or a one-man shop, I could see why you might not come out of the gate with captions/transcripts. But even that only works to a point. If you’re pouring hundreds of dollars into a good headset or other higher-end audio equipment, then at some point you should be making arrangements for captions or transcriptions. It goes without saying that Harvard and MIT aren’t in the one-man-shop category.

Read VPN - a Very Precarious Narrative by Dennis Schubert (schub.io)
A very long article about commercial VPNs, their marketing strategies, and the truth behind their privacy and security claims.

[…] another worrying aspect of today’s market of VPN services is the large amount of misinformation end users are exposed to, which makes it hard for them to properly tell apart vague and bold claims typical of product advertisement campaigns with actual facts.

That quote is four years old, and just as relevant today as it was when it was written. The article I’m linking here does a really good job explaining what a VPN (virtual private network) is and what it is not, and it makes sure to use as few technical terms as possible. It also goes into detail about what a VPN is good for, not just what they’re not good for.