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 (

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.

Read Stop Throwing Away Your Content by Adrian Roselli (Adrian Roselli)

It is not uncommon for individuals and even entire organizations to rely on some third party platform to host all their thought-leadering. Medium is the common choice, but many use other platforms as well, such as LinkedIn.
While many argue that the reach is better and it is easier than self-hosting, few consider what will happen when their chosen platform goes away (or the platform chooses to purge you). After all, the web is littered with the corpses of platforms populated by content that you wrote and that we will never see again.

The death of GooglePlus earlier this week is the perfect time to re-up this from Adrian. With the rate of site deaths or just general data loss, like in the case of MySpace and all the music, this will never stop being evergreen content. Seriously, listen to Adrian and do what he tells you. Start taking control and ownership of the content you create.

Yesteray I opined on the latest Jetpack release, calling its search suggestion feature way over the line. I had a subsequent Twitter conversation with several people in the WordPress community, in which the stated intention behind the feature by one of the main developers was to solve the pretty significant problem of users installing multiple plugins which perform the same task. I know the developer and I have no doubt that that particular developer’s intentions are good and even admirable, so before I go any further with this, I want to state that it is not intended on my part to be a personal attack on any of the humans involved. I’m specifically keeping names out of this because I do not want anyone to be personally attacked as a result of this. With all of that said, I just test-drove the feature, and if that suggestion isn’t an ad, I really don’t know what is, and I suspect that anyone else who comes scross this, (especially screen reader users), are going to perceive this as an ad, even if it really isn’t intended to be one.

Steps To Reproduce

You must be running the latest version of Jetpack. If it’s not showing up in your updates, it will soon if you have it installed. I’ve run the update on my personal site, and got the following results when testing.

I searched for Jetpack’s sharing feature by typing the word “sharing” without quotes into the search box on the plugins/add new page. I specifically have this feature disabled. What came back is the following.

Aftere searching, and the page refreshes, the first thing I find on the page when navigating by headings after searching is “Jetpack: Sharing” at heading level three, just like every other search result on the page. Next, in the list below the heading with a link, (which normally contains a link to install the plugin and a link to learn more about it), I find a button labelled “enable”, followed by the traditional “Learn more” link.

Next, there’s a description of the feature:

Add Twitter, Facebook and Google+ buttons at the bottom of each post, making it easy for visitors to share your content.

The plugin author name follows directly after this, and in this case it’s Automattic.

Next is a graphic without alternative text, which I can only assume is the Jetpack logo or maybe the Automattic logo. No matter what it is though, so far the only thing distinguishing this from a standard search result is the replacement of the “install” link with an “enable” button, and this graphic. Otherwise it looks like a standar search result. Now onto the other very minor differences.

Under the graphic without alternative text, the following text appears:

Jetpack is trusted by millions to help secure and speed up their WordPress site. Make the most of it today.

Marketing copy complete with a call-to-action.

And now, for dismissing the suggestion. There’s some text that says “Hide this suggestion”, and although this appears to not be associated with any discernible element while using a screen reader, if you press enter on it, the suggestion disappears. However, your focus jumps down to the nex item in the list, past the heading to the end of the list with the two links, so you have to press shift-H to navigate back to the heading to find out what you’re even working with.

The focus management and alternative text issues are fixable, as is the semantics of the “Hide this suggestion” thing. However, all of this seems confusing at best, requiring me to pay extra attention to what’s going on on this screen. I spend a fair amount of time in the WordPress administration panel, and I expect that between plugins, themes, admin notifications, and WordPress in general, these screens are going to change. However, needing to pay extra attention to the plugin search screen so I can avoid accidentally enabling a Jetpack feature due to something that is definitely an advertisement dressed up to look like a search result is absolutely not OK. I knew what was coming, and I still needed to focus on what I was doing to a much more greater degree. Anyone who doesn’t realize they have Jetpack installed, (and this happens a lot considering that hosts install it automatically in a lot of cases), is not going to spend the bit of extra time to pay closer attention to what’s going on, and therefore will enable a feature, at which point they then will need to dig through settings to find where it’s buried once they realize they’ve enable something they don’t want, or God help them when there’s a conflict with something on their site, as their was with the Jetpack sharing buttons markup and the Microformats 2 markup on my personal site, which prompted me to disable the sharing buttons in the first place since I prioritize correct markup over whether or not someone can click something to share my post.

All of this looks incredibly shady, even with the consideration of the stated intentions behind it, and I find myself asking: who dictated the design and development requirements of this user experience? It may be designed to be visually separate from the rest of the search, I don’t know. I haven’t gone through the CSS. But it sure as hell isn’t very different markup-wise, and yeah, that makes me kind of angry. I suspect anyone who encounters this without knowing anything about it, or any of the humans involved, is going to be angrier, never mind feeling tricked, and I really think this was completely avoidable.

I use Jetpack on some of my sites, as well as some client sites. It provides a lot of features that site owners will need, without having to install a bunch of plugins, and does so reasonably accessibly. However, the latest release, (7.1), quietly adds Jetpack feature suggestions to the plugin search screen. From The Tavern:

If a user searches for a plugin that has a feature that is already offered by Jetpack, the plugin will insert an artificial (and dismissible) search result into the first plugin card slot, identifying the corresponding Jetpack feature.

This is so far over the line of what’s acceptable and what’s not, it’s not funny. I’d be livid if any other plugin did this, and the fact that Automattic is doing it, combined with its incredibly large amount of influence over the WordPress ecosystem, is enough to make me seriously consider uninstalling Jetpack from every one of my sites. The WordPress dashboard and administration screens are already choked with advertisements and useless nags thanks to other plugins and themes. The fact that Automattic is essentially giving this a blessing is, I suspect, going to make this problem worse than it is. The web is supposed to be independent and decentralized. Automattic is supposed to be helping to ensure that an open, independent web survives, or at least that’s what its CEO appears to be leading us to believe. Driving an ecosystem to use the features of one plugin over everything else is an attempt at centralization, which is obviously in direct opposition to an open, decentralized web. Getting back to the accessibility question, while Jetpack does some of the things it does reasonably accessibly, does this mean that Automattic is going to put some extra muscle behind making sure that every one of its features are accessible? If you’re going to exercise undue influence over plugin search results, effectively cutting off the air supply of anything that may provide a Jetpack feature more accessibly, then you take on the responsibility of ensuring that accessibility is looked after. I think I already know the answer to these questions, but I decided to pose them just in case. You know, in case I happen to be dead wrong in my supposition. At the end of the day though, I’d rather Automattic just not game the plugin search results.

If you work with Windows Server or Microsoft’s Azure platform on even a sporatic basis, (and especially if you work with either on a regular basis), Powershell is the most efficient way to get things done. People with disabilities can now enjoy this level of efficiency on a more equal level with our sighted counterparts, because a href=””>Microsoft has put a lot of work into making its powershell gallery more accessible, including working specifically with blind systems administrators to ensure that the work they’ve done to make the gallery more compatible with screen readers actually benefits real peoplein real work situations. Microsoft has come an incredibly long way in the last eight years with regard to accessibility, and I for one think they deserve a ton of credit not for doing the right thing, but for doing their utmost to go above and beyond standards compliance and making sure people with disabilities can get our jobs done on par with our sighted colleagues.
Current status: Making some edits to my CSS to fix some color issues and link underlines thanks to some extremely helpful and detailed feedback from a reader. I will also submit these changes to the relevant theme repos on GitHub. Feels great to improve
If you’re waiting to add accessibility to your projects until your clients ask and pay for it, please rethink your strategy. Accessibility is not a feature. It is not a nice to have. It’s harder to do when you bolt it on after the fact instead of building it in at the start, and the only thing you’re doing with this approach is creating more work for yourself, more hardship for your clients, and a shitty experience for people with disabilities. Please do not do this. Add as much aas you can by stealth if you have to. If your client asks you for some functionality, build the accessibility in without their permission if necessary. If the eclient balks at accessibility, (this does happen), walk away. I’m telling you to do that because I’ve done it myself. I promise you that if they’re balking at accessibility there’s a pretty safe bet they’ll balk at other best practices too, and then blame you when things go south because best practice corners were cut.

From The Evening Standard:

Next has become the first major British high street retailer to sell more to its customers online than through its network of more than 500 stores.
The historic crossover came at the start of the new financial year in February, according to chief executive Lord Wolfson, with the gap set to widen rapidly through 2019.
It will send further shockwaves through a battered retail sector already struggling to adapt to the accelerating shift from “bricks and mortar” to digital sales.

Wolfson hails this as a thing worth embracing, saying that people in small provincial towns now have the same buying options as those who shopped on Oxford Street ten years ago. Everybody wins, right? Not exactly.

If you’re a person with a disability, Next has gone to the trouble of building a separate website which supposedly cators to the needs of those who need accessibility. Problem is, separate is not equal, and it never has been.

This is another one of those conversations we shouldn’t be having at this point in the web’s history. For one thing, as already mentioned, separate is not equal, and even law/policy, as incoherent as it is, agrees on this, at least when it comes to certain industries.

For another thing, separate websites for people with disabilities are often not maintained, (looking at you, Amazon), and are a resource vampire for both the establishment for which they’re built as well as any web design or development staff, in or out of house. If anyone seriously suggested thata we build separate websites for phones, tablets, large screens and watches, they’d be laughed out of the room by pretty much anyone who builds or designs things for the web. No one would dream of wastiing time and resources like that. So why is it still all too common to see large organizations building separate websites for people with disabilities?

Web-based discrimination is just as unacceptable as real-world discrimination. It’s not OK to build separate but equal for browsers, and it’s not OK to build separate but equal for people either, and people with disabilities are people first and foremost. Seriously, if you’re a web developer or designer and you’re being asked to build a separate site for accessibility purposes, please push back on this. I’m not going to lie, you may have to walk awa from a contract or to. We, however, are the only ones who can really change this situation. These things wouldn’t be built unless we as an industry weren’t willing to put in the elbow grease to build them. We’re not just pairs of hands, and if we as an industry could manage to move the needle from building one-size-fits-all websites to building websites responsively, then we can move the separate but equal needle too. Let’s do this already.

From Disability Scoop:

The federal government is accusing Facebook of illegally using its advertising platform to discriminate against people with disabilities and other groups.
The U.S. Department of Housing and Urban Development charged the social media company Thursday with violating the Fair Housing Act. The agency said Facebook is “encouraging, enabling and causing housing discrimination” through its method of allowing advertisers to control who sees ads for homes. … According to the charge, Facebook allows advertisers to exclude or include users from seeing ads based on various attributes including interests in “accessibility” or “service animal.”
Furthermore, the charge alleges that Facebook’s system is set up in such a way that it won’t show ads to groups it considers unlikely to engage with them, even if the advertiser has explicitly targeted those groups.
As a result, “ads for housing and housing-related services are shown to large audiences that are severely biased based on characteristics protected by the (Fair Housing) Act,” according to the charge.

At last year’s National Federation of the Blind convention, Facebook stated that

one in ten people use the zoom feature on the desktop browser, 20 percent of people increase the font size on iOS, and over 100,000 use screen readers on mobile devices to view Facebook.

(Source). It didn’t take very long for what amounts to tracking those with disabilities to go from something benign to something used as a tool of discrimination. The fact that the self-styled “voice of the nation’s blind” essentially aided and abetted this isn’t surprising. And yes, the NFB owns part of this. That organization gave Facebook a platform and its blessing to essentially brag about its disability tracking efforts, and were silent when questions were raised concerning how that data was gathered. If I were a member I’d be pretty pissed right now and I’d be demanding answers from the leadership.