I’m not one to throw around the “not-a-real-accessibility-advocate” label, but if someone exhibits a pattern of excuse-making for inaccessibility on behalf of themselves or others or both, they need to hand in their A card. Same if that extends to encouraging fellow people with disabilities to accept excuse-making for inaccessibility. If you do all three then you probably need to be taken to the proverbial woodshed because excuse-making for inaccessibility is never, ever acceptable. Either you believe it’s OK to discriminate or you don’t. It’s that simple. Signed: Someone who was once rightfully taken to the woodshed.
Shoutout to all the automatticians currently slogging through the VIP Go outage, from the people on the front lines dealing with customers to the people behind the scenes in the proverbial basement who are usually never noticed until something goes wrong. Support and server maintenance are often thankless jobs, but without people like you this stuff doesn’t run. I don’t work with y’all, and I’m not a customer, but I see no reason why we can’t support each other from afar.
Read The difference between keyboard and screen reader navigation by léonie Watson (Tink)

People often include screen reader users in the much larger group of keyboard-only users. Whilst this is correct (most screen reader users don’t use a mouse), it also creates a false impression of the way screen reader users navigate content.

This is a really good primer for anyone building things for the web as well as screen reader users on the differences between screen reader and keyboard navigation. I’ve seen lots of situations where the two are conflated, by both developers and screen reader users.

Also, I really like the footer text on léonie’s site.

Read Source Order Matters by Adrian Roselli (Adrian Roselli)

CSS is providing newer and more complex methods of laying out your pages. Given the multiple form factors a responsive site has to support, it makes sense that developers want easy ways to structure the layouts that aren’t all floats, clears and position: absolutes.
Regardless of how you want your layout to appear in a browser, you must keep in mind that a clear HTML structure is [start of stricken text] important to search engines[end stricken text] . Sorry, while the bit about search engines is true, it’s not really what I consider important, but it is more likely to get some people to pay attention.

I still think it’s pretty messed up that, for the purpose of getting the topic of equal access for all on the web some play, we have to refer to the benefits for search engine optimization, (most of which are myths), because that’s the only way most people are going to pay attention. It’s either that, or try scaring people by reminding that eventually, they won’t be fully abled. I get it, I’m not going to stop doing it, but it’s still one of the less-desirable, less-lovable parts of accessibility for me.
I’m helping a screen reader who has been recently introduced to WordPress configure their new site, and noticed that they were becoming frustrated with the clutter of their WordPress administration menu thanks to plugins arbitrarily adding things to their top-level menus and inserting their own top-level menus in between the out-of-the-box ones. I had them install Menu Humility by Mark Jaquith. Despite the plugin not being updated in over a year, it still works exactly as it is intended, and I install it on every new site I build and every site I rebuild. I’ve mentioned this plugin before on this site, but wanted to mention it again because I find it so useful in my quest to minimize the trashfire that can result when plugin and theme authors clutter the dashboard in order to fulfill their own hopes or desires for more downloads or upgrades with no regard for the users actually using WordPress. If you’re running the latest version of WordPress, (and you really should be), upon viewing the plugin in the plugins/add-new screen, you’ll get a notice that says “untested with your version of WordPress.” In this case, ignore that notice, because this still works, thanks to WordPress’s commitment to backwards compatibility. This isn’t so much an accessibility issue as it is a “get off my lawn, stop cluttering my dashboard with your crap, my dashboard isn’t your playground” kind of scenario. Menu Humility isn’t the only plugin that can help with dashboard clutter, but it’s the first step to making it a saner place which induces less rage. Go get it if you haven’t already.
Read HTML Source Order vs CSS Display Order by Adrian Roselli (Adrian Roselli)

Last month in my post Source Order Matters I wrote about why we need to consider how the source order of the HTML of a page can affect users when the CSS re-orders the content visually. While I used a recipe as an analogue and cited WCAG conformance rules, I failed to provide specific examples. I prepared one for my talk at Accessibility Camp Toronto, but have since expanded on it with more examples.
I want to make sure that we all understand that the source order versus display order discussion is not unique to CSS Flexbox. It is not unique to CSS Grids. Many developers have been dealing with this (correctly and incorrectly) since CSS floats and absolute positioning were introduced (and even earlier with tabled layouts). As such, I have examples of each in this post (no tabled layouts).

Worth a read and reread by anyone doing anything with CSS. For some reason, Adrian’s feed was not in my RSS reader. This is now fixed.
Dear fellow developers: If you’re one of those developers who makes it impossible to press the tab key to move through a screen, hand in your dev creds now and put down your IDE until you learn to do better. I should not have to get help from a sighted person to add FTP users to a server. This is becoming a serious problem. Learn HTML damn it! Learn HTML as if I am going to find out where you live.
Read The Mac Open Web (Bitsplitting.org)

These days, as the giant social networks behave more and more reprehensibly, many people are looking back to the “good old days” of the web, when self-published blogs were the primary means of sharing one’s thoughts.
Brian Warren has taken this enthusiasm, and combined it with his nostalgia for another classic resource: the links page.

This one is devoted to all things Mack and iOS that allow you to consume and create content for the open web. I don’t have a Mack, and have not gone through all the iOS apps yet, so you’ll have to test the accessibility of some or all of these apps for yourself. Indieweb developers are very open to accessibility feedback though, and this includes implementing things for the sake of accessibility, so this is sort of the one place where productive conversations about accessibility which don’t involve accessibility folks talking to each other are still possible.
Read Defining PDF Accessibility by WebAIM: Web Accessibility In Mind

When people talk about “accessible” PDF files, they are usually referring to “tagged” PDF files. PDF tags provide a hidden, structured representation of the PDF content that is presented to screen readers. They exist for accessibility purposes only and have no visible effect on the PDF file. There is more to an accessible PDF file than tags, but an untagged PDF would not be considered “accessible”.

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.