Speaker Submissions for the Second Annual JavaScript for WordPress Conference Are Open

The 2nd Annual JavaScript for WordPress conference is scheduled for July 11 through 13 of 2019, and will include 3 FREE Days of workshops, talks and contribution all focused on JavaScript and WordPress. Workshops include learning how to use modern JavaScript development tools to write custom vanilla JavaScript in WordPress themes and plugins, as well as learning how to load and write React in WordPress plugins and themes. There’s a day of free talks separated into two tracks, and conference organizers have opened the speaker submissions. You can apply to speak and register for the conference on the conference page, as well as listen to past sessions. I was not able to attend this last year but will definitely catch up on past videos.

Notes from: “Who’s Afraid Of ARIA?” at WordCamp US 2018

Rian Rietveld @ #WCUS:

Rian is demonstrating Voiceover and ARIA for the WordCamp audience.

She’s giving a very practical example of why semantics matter when it comes to the web.

Aria-live: Tells screen readers what’s changing on a page without refreshing the page.

aria-live allows dynamic changes to be announced by screen readers.

From earlier in the talk: First rule of ARIA: Don’t use ARIA. Use a native HTML 5 element first, then add ARIA *when necessary*.

Make sure when using aria-live that your announcement is not too verbose: For example: announce the number of search results, not every search result.

Overrule a link’s anchor text with aria-label. Beware: aria-label overrules a link’s anchor text completely. For screen reader users it’s as if the link text does not exist.

screen reader text class: Hide something from sighted users while announcing it to screen reader users.

Use screen reader text class with the span element.

Aria-describedby and aria-labeledby: aria-labeledby replaces label text, (see form elements), aria-describedby adds extra information to the label text.

Rian is able to turn VoiceOver on and off. This would never happen using Jaws. You can do it with NVDA though. Sorry, couldn’t resist.

Make it work before you make it nice.

Slides for this talk, code with examples is here, and you can watch “Who’s Afraid of ARIA” with captions here.

Notes From: “Content Security Policies: List Your Trusted Sources And Prevent Attacks” at WordCamp US 2018

Miriam Schwab @ #WCUS:

Why is cryptomining from websites bad? Because it eats resources, plus governments shouldn’t be cryptomining.

Magic Cart: Going on for last three years, no one knows origination, attack ID’s third-party scripts on websites and then hacks scripts.

Magic Cart hacks scripts for the purpose of skimming credit card information.

Content security policies: white-list sources via browser header, if a source is not white-listed, it can’t be installed. Applies to trackers and other third-party web scripts like Google Analytics or Google Fonts.

Demonstrating code snippets which implement content security policies, will share slides later.

Includes log of violations of content security policies. I’m going to love looking at this code.

If you research content security policies online, not a lot of upp-to-date information, CSPs have been around since 2012.

W3C’s docs critiqued as being illegible, especially for those who speak English as a second language. Agree. Internationalization FTW!

Google is “do-as-we-say-not-as-we-do” with regard to its CSP docs V. what it does with its Google Analytics and other scripts.

Keeping up with what’s been added to pages manually is hard. Use Scrict Dynamic CSP instead. One policy across multiple pages.

Google has tools for CSPs: Strict Dynamic Test Bed, not sure of accessibility of tool will need to check later.

CSP can be added using meta tag or in theme’s functions.php file. Also .htaccess. Use these if you don’t want to work with browser headers. Probably can stick this in custom functionality plugin too.

CSP Mitigator from Google: Check http response headers, if no CSP present, will alert. If CSP present but there are problems with it, tool will offer suggestions.

There are also WordPress plugins for this, not recommended because some are out-f-date, but easy way to get started.

report-uri.com: Alternative to CSP Mitigater, useful if you have issues philosophical with Google.

Google’s resources making it possible for more people to implement CSPs.

Now demoing offline copy of White House website: No CSP, which means things can be injected client-side.

For the blind people playing at home, the injection to the Freedom scientific website changing the site tagline to “Too expensive products for the visually impaired” was a result of no content security policy being present on the site. Not from speaker, my own injection of another example.

Thank You, Louis Braille

Today marks the two hundred and ninth anniversary of the birth of Louis Braille, the inventor of the system of dots which bears his name and has enabled blind people all over the world, including myself, to read and write. This day is commemorated as World Braille Day, and in appreciation of the gift loaded with opportunities braille has provided me, I wanted to write a short note of thanks and gratitude as my Ultimate Blog Challenge post for today.

I’ve been a braille reader since about the age of five, and shortly after that, a braille writer. Braille was how I and my fellow students in the classes composed only of blind children I attended in my early school years learned to read, write, spell, and do math. I still enjoy reading braille whenever I can, using a braille display, and I honestly can’t conceive of my life without it. Braille has enabled me to contribute to the world around me, as well as cook, write code, and read for pleasure. Braille has made it possible for me to more concretely retain knowledge. I can learn by listening to either a screen reader or to an audio book, but there’s nothing quite like reading and then digesting as opposed to a near constant stream of spoken words that are coming in while the last ones I may have heard are still in the process of being internalized.

Several of the things I am sentimentally attached to involve braille: The box of birthday cards from my grandma which all have their messages in braille; the little porcelain shoes I received as a gift from Rian Rietveld at the final WordCamp U.S. with their attached note in braille; the purse charms I bought myself last year from elegant Insights Braille Creations with their embossed braille phrase. For me, nothing preserves memmories quite like braille does.

So, thank you, Louis Braille, for the privilege of being able to read and write, and thereby contribute to my world. Thank you for the enjoyment, and the ability to read when the power’s out, and the ability to capture memories in a way that will outlast almost every form of technology. Thank you for everything.

A Meditation On Arrogance In Tech

Today’s Ultimate Blog Challenge post will be a quick one, because it’s been a very long day with very few spoons and I’m very tired. The prompts for today revolve around the people we admire in either our personal or professional lives, but instead of focusing on who I already admire, I wanted to write a bit on where I think we need to be headed if we want to become people and a profession that people who are not part of our “in crowd” can trust when we make promises, (explicit or implicit), regarding improving their lives and not screwing them up. This is more of a meditation than anything else, so it’s a bit rambly.

Every day, I come across articles in my various news feeds about the latest moral or ethical outrage in tech. They’re usually different kinds of moral or ethical outrages, but I think they all stem from the same root problem: Arrogance on the part of the tech industry. I think, as a general rule, our industry tends to not think about the negative effects the things we create can have on society in general and the lives of individuals in particular. We tend to view the idea of tech taking over everything as a good thing, we assume that whatever we’re creating is part of that goodness, and when someone does bad things with it, we come back with something along the lines of “We can’t control what people do with our stuff.” We pretend that the things we create are neutral and that we as an industry are a shining city on a hill, when really neither of these beliefs are true at all and are prime examples of our telling ourselves what we want to hear and believe instead of acknowledging the realities of the situation: Technology is not neutral, we have a lot of power over society and over individuals thanks to tech being as pervasive as it is and getting more pervasive by the day, and while we can’t prevent every bad actor from using what we create, we could work a lot harder to make it more difficult to do horrible things with our creations. We’re not building neuclear bombs, after all.

If we want to become an industry the public can trust, we need to get our stuff together, and we can start with stripping away the arrogance. I’m thinking of a certain type of founder here, but really, we’re all susceptible to it. It’s really easy to convince ourselves that we’re drowning in awesome sauce, that everything we do has zero ethical problems, but that’s mostly because we generally refuse to consider ethics in tech, and so since we’re not considering it as a discipline, there must not be a problem. But ignoring a problem doesn’t mean it doesn’t exist, and the longer we continue to ignore this as an industry, the worse it’s going to get. And eventually, as people become more technologically literate, they’ll begin to look more closely at what we do outside of code as well as inside it. We cannot continue to freewheel through people’s lives, reduce them to one-dimentional users, and then walk away from the consequences that inevitably result from our actions. None of this is to say that the things we create are evil by default. I still believe that we can do a lot of good in the world. But we need to concentrate on making sure that we’re actually creating things that are beneficial, and guard against our creations being used for evil as extensively as we can. In short, we need to grow up and start demonstrating that we have the capacity to act ethically and responsibly.

Introducing Myself To The Ultimate Blog Challenge

The Ultimate Blog Challenge presents so many opportunities to get to know other people and build relationships with them, and the best way for this to work for everyone is for all of us to be as human as possible with each other. I think this is why one of the starting posts is an introduction.

I personally find introductions where I have to say nice things about myself hard to write, but another one of my 2018 goals is to do more self-promotion while not becoming annoying or conceited about it, so here’s my introduction to the rest of the participants of the January 2018 Ultimate Blog Challenge.

My story on the web begins with a course on HTML I took as part of my computer science studies back in 1998. It was my favorite part of that year’s curriculum, and I spent the rest of my school career and early work years tinkering with web technologies. I use a piece of technology called a screen reader, because I am totally blind. This meant that I needed to make sure that my web tinkerings had an accessible result, because if they didn’t, I myself would not be able to use them. So along with experimenting with things like HTML and CSS, I used tools like Bobby along with manual testing with my screen reader to make sure that I could use what I created.

In 2005, while I was trying to solve the problem of displaying the Hebrew date on my very simple blog, I ran across WordPress. Never having used free licensed open source (FLOSS) software before, I assumed that WordPress was going to cost me and that the plugin I needed was going to cost me further. This was not the case. So after work one day, I decided to go through the famous five-minute install, and I had WordPress up and running on this site, which at the time was my personal site on the web.

During the day I went to work at my job, and after work I experimented with WordPress. This included hacking themes and plugins, breaking things, and learning how to fix them.

Then, one day when I went into work, I found that the software I needed to use to do my job became completely inaccessible. This meant that I literally could not do my job. There were some attempts by our operations manager at the time to try to get the software fixed, but since the call center I worked for didn’t have control of the software, those efforts amounted to something along the lines of “we’re terribly sorry our software doesn’t work for you, and here’s this other blind guy who works for the same call center you do, and this other one who works in-house with us, and maybe you guys can come up with a work-around.” Spoiler alert: We didn’t.

When the effort to get the software I needed to use to do my job proved unsuccessful, the next option according to the call center was to terminate my employment, hand me a severence package, and send me on my way. Of course I was deeply unsatisfied with this option, because I had done nothing to warrant termination, and a severence package wasn’t going to make the fact that I was going to be out of a job any more palatable. Fortunately, I had a supervisor who was willing to go to bat for me like nobody’s business, along with a systems administrator who was willing to bend the rule about low-level employees not having anything but restricted internet access on their work stations.

So because I wouldn’t agree to the termination and severence package, and because the call center I worked for didn’t want a discrimination lawsuit on their hands, I spent my last two years at that job hacking on WordPress for eight hours a day.

In mid 2007, I accepted a tech support role with Freedom Scientific, a veteran provider of assistive technology for individuals with blindness, low-vision and learning disabilities. This was my first position involving remote work, and I continued to hack on WordPress after work while supporting users of Freedom Scientific software by day, assisting with installing their flagship product, Jaws for Windows on individual machines, as well as configuring license servers to work with various corporate and government firewalls and networks. My duties also included supporting users of notetakers such as the Braille ‘N Speak, which you can see demonstrated in the below video.

Things were going great until I received an email one Saturday morning from my manager at Freedom Scientific letting me know that my hours had been reduced to zero, and that once I sent my phone and other equipment back I would receive my last paycheck. I now had a ton of free time on my hands, and no income. I applied for Social Security Disability and waited for that to kick in, while living off the six months’ worth of pay I had saved. I also decided to go back to school to obtain various Cisco and Red Hat certifications. I thought that these would be my way back into the workforce. I was very wrong.

As I began taking courses for my certifications, I learned that the certifications themselves were completely inaccessible. This meant that I could take courses all day long, but I couldn’t pass them because the certifications were required as part of the final grade. My GPA tanked, I lost my financial aid, and everything started cascading down from there. My health took a turn for the worse and I was diagnosed with Lupus eventually, I was evicted from my apartment, and I moved to Augusta, Georgia because my friends Wil and Denise offered me a couch and a roof over my head.
I was still hacking WordPress through all of this. It was the only stable part of my life. I wanted to help make it more accessible for people with disabilities, so I googled WordPress and accessibility and stumbled on the WordPress Accessibility Team in 2012. I was elated that it existed and joined up. Shortly after that, I finally got my own place to live, and started thinking about what I was going to do with the rest of my life in regard to work. I thought I could build things with WordPress for a living, but wasn’t sure if anyone else was doing it. I had heard stories, but figured they were one-offs and assumed given my recent string of failures that I could never pull it off.
I had begun listening to podcasts by this point, so I started looking for WordPress-related ones. I stumbled on the Drad Cast. I was expecting it to be full of technical things, but not very entertaining. Wrong again. I loved it. It was WordPress, beer and hilarity all rolled into one. And they talked about security as well, which is another subject I’m passionate about, along with accessibility. When the Drad Cast announced that WordSesh was going to happen, I was stoked. It was twenty-four hours of WordPress crack, and it was completely online. This was good because travel was out of the question. I made sure to tune in and stayed up the entire time listening to and absorbing WordPress knowledge. I also started interacting with WordPress people on Twitter, and learned about the wider community and how awesome it was. A couple of months after that I started using Genesis, which made WordPress development quicker as far as the front end is concerned. And I was still contributing as part of WordPress Accessibility. Things had finally started to pick up.
In 2014, I filed for incorporation in Georgia, and Customer Servant Consultancy became an actual entity. It was the name I had been operating under since I started building things with WordPress for other people and I was glad to make it official. It was also around this time that I started building internal systems with WordPress to manage projects and customer relations. Since WordPress is open source, and becoming more and more accessible by the day, I was able to gain more independence because I wasn’t at the mercy of web and application developers who know nothing about accessibility. I could build it myself as long as I had the time.

Fast forward to 2018, another year full of promise and potential. The internet is ever-changing, and the WordPress community is going strong. I never expected to find my nitche through a random web search so many years ago.

I’m Joining The January 2018 Ultimate Blog Challenge. Here’s Why

It’s time for the January 2018 Ultimate Blog Challenge, and I’m jumping in with both feet. I wanted to write a quick post both as my first post for the challenge and as my first post of 2018 to explain why.

Several of my goals for 2018, (goals mind you, not resolutions, simply because I don’t like all the social baggage that comes with that term and I also hate conformity), revolve around my websites. I’m working on aligning my personal and professional site (this one) with the principles of the indieweb, and part of that effort involves writing less content specifically for the various social media silos and more on my own sites, which then gets syndicated to social media silos. I thought that joining with a group of people who are similarly interested in bolstering the presence of their own blogs would be a great way to help accomplish this, as well as build some new relationships. I’ve also got a ton more writing to do for the WordPress with a Screen Reader series, and writing shorter posts each day will exercise the writing muscles I need for that series. I’m looking forward to reading what everyone else has to write, commenting on those posts, and adding my own posts to the effort.

If you want to join us, you can visit the Ultimate Blog Challenge website, and sign up for yourself. There’s also a Facebook group as well as a Twitter hashtag you can follow to read submissions from other participants. I’m looking forward both to my part in the challenge, as well as interacting with everyone else. Welcome to 2018, everyone.

Spooled Twitter Thread: OK Third-Party WordPress, We Need To Have A Come-to-Jesus Meeting About Your Accessibility Flare

This post originally started as a Twitter thread. Since those can be difficult to read in some circumstances, and since this content is I think valuable for more than just WordPress Twitter, I’m spooling it up and re-sharing as a complete post. I’ve also added a link and a video to this.

OK third-party WordPress, we need to have a come to Jesus meeting about your accessibility flare. The day I hoped and prayed would never arrive, and which I feared would get here despite my wishes, is here. People and organizations who choose WordPress because of its power and flexibility, and yes, because it can often be easier and less expensive to use than creating a custom solution, are being served with demand letters regarding the accessibility of the websites they build. Websites they build with our themes and our plugins. I have two clients in my cue right now, both within a matter of days, who find themselves in this position, and they’re lawyers have already responded to the demand letters agreeing to terms. This is good for business, for obvious reasons. But it does not make me happy at all. Not one bit. The fact is, I want people to build accessible websites because it’s the right thing to do, not because they have to be sued into compliance or bullied into same. We, as software creators, have a responsibility to ensure that we don’t put them in this position, whether the plugins they use or the theme they use are premium or free. The resources are out there for you to learn how to write accessible code and how to design accessibly. Trust me, this is not some sort of “Hey your stuff sucks, hire me and I’l help you fix it” marketing campaign. I want you to fix your stuff, regardless of whether or not I get anything out of it. I want people who use WordPress to be able to rest assured that, when they build with our stuff, they are building things that are inclusive of everyone, without having to ask. I want people to be able to build accessible websites without having to hire someone who specializes in accessibility to do it for them. I do not want some momblogger to be served with a demand letter, only to find that the site they built with a $100 theme and some free plugins is now going to cost them thousands of dollars any way they cut it. The only people who really win in these senarios are the lawyers sending the demand letters. There’s consequently a backlash brewing in the legislature, which if successful, will further punish people with disabilities by restricting the already-limited solutions we have for resolving accessibility complaints. And make no mistake about this, people with disabilities are not at fault for wanting their civil rights to be upheld. Accessibility is a civil right. This talk explains.

WordPress now powers close to 30% of the web, or even if you don’t like that stat, still a sizeable portion of it. With that kind of reach comes responsibility. We can say all we want that it’s the responsibility of the people building the websites to look after accessibility. That’s fair when the only people building websites are web professionals. But web professionals are far from the only ones building websites. We, as people who build for WordPress, are not responsible for what any other platform does. But we are responsible for what we do. And we build plugins and themes like it’s going out of style, which people then download and use to build websites. We have an obligation to ensure that we don’t expose them to risks like this without their knowing it. In a lot of these cases, if some small organization or business gets a demand letter, their only recourse is to take the site down, since they could never afford to spend thousands of dollars on a custom website in the first place. That means their voice goes silent. We are in the business of democratizing publishing. That also extends to building the actual website. And the thing is, this is completely unavoidable, and by unavoidable, I don’t mean in exchange for people with disabilities putting their civil rights on the back burner. This situation should not be happening, and we, as the creators of this software, have an opportunity to help stem some of this, and a responsibility to do so. I am serious. I do not want to see another urban clinic, or another non-profit, or another momblogger, served with a demand letter and faced with a bill in the thousands of dollars for fixing it because they chose WordPress instead of a custom solution. Of course, I will fix sites, switch out plugins and themes, ETC. But this is not the way accessibility should be mainstreamed. Bringing the legislative hammer down on people with disabilities is not the answer. Waiting on the Department of Justice to get its act together and settle this is also not the answer. But third-party WordPress, this game where accessibility is a nice-to-have or an afterthought is over. With or without my help, start getting your crap together. Seriously. And yes, Envato, this especially includes you, because let me tell you what’s happening. Someone wants/needs to build a website, and so they go looking for the perfect theme. So they google, and they land on ThemeForest, and find the perfect theme with all the right features, pretty demmo, all that. They then buy it and set it up, caring nothing about proper theme architecture, bundling plugins, none of that. And then, they get served with a demand letter or lawsuit. And they don’t care how the theme was built/what makes up their website. They care that they were able to spend $50-$100 and have a presence on the web. And Envato, the majority of those sales are going to you and your authors. So I do not care if you have to make a mandatory rule stating that no theme can exist on your site without following the WordPress theme accessibility guidelines, do it. I don’t care if you then have to take those theme guidelines and apply them to the front end of the plugins your authors bundle in. Do it. Obviously this goes for the rest of you too, but Envato is huge in this. So once again, get your crap together, do your f*cking jobs, so your users don’t walk into this unaware.

Working With WordPress’s New Media Widgets While Using A Screen Reader

2017’s two major WordPress releases introduced several new widgets. Audio, video, gallery, and image, among others. Most of the new widgets are media-related, and require users to interact with WordPress’s media modal and media library.

The media modal has been a source of significant frustration in the past for screen reader users, unless you use a specific commercial screen reader and your version of that commercial screen reader is up-to-date. The level of frustration has been significant enough to discourage people who use screen readers to leave out media on their sites altogether and opt to use closed platforms to share their media instead.

And yet, you can’t build a modern site without some media included. Media like images can help break up walls of text, making your content easier to read. This means that the media modal is unavoidable. Thanks to incremental improvements in both the code used to build the WordPress media modal, as well as improvements in NVDA 2017.4, the frustration level has been significantly decreased, and while the experience isn’t completely frictionless, adding media to widgets, posts and pages is no longer something that’s a stretch to reach for people who use screen readers.

I decided to turn this section of the tutorial on widgets into its own separate post for easier reference, and because the general widgets tutorial is already long. This material will also come up again when we get to the sections on editing and creating posts and pages, and I’ll reproduce these steps in those sections so you don’t have to refer back to this post in order to find them. I’ll go through adding the audio widget step-by-step, from first adding the widget to selecting audio for it. Because the process is almost identical for the image, video, and gallery widgets, I’ll note the differences between these and the audio widget. With all of that said, let’s get started.

Help Keep This Series Free

$685 of $20,000 raised
Each post in this series takes a significant amount of time to research,
write, and edit. In order to make this effort sustainable, I would need to
charge a minimum of $100 U.S. per month in order to compensate for the time
it takes to write this material and the size of the screen reader users
market, which is around 5% of the total market of people with disabilities. This series benefits the whole WordPress community as we strive to create a
more open and more inclusive internet. The group of people who will benefit from this series the most are also the
least equipped to afford to pay a fee like this to access it. In the United
States, as of 2015, 58% of the blind
community is unemployed, and 29% live below the poverty line. Most of these people live
on a fixed income that is less than $1,000 per month.

Your sponsorship will ensure that everyone who uses screen readers
with WordPress get the same opportunity as those who do not use screen
readers: documentation they can freely use to learn WordPress, similar to
what exists in the WordPress Codex for mouse users.

This content has to stay free for screen reader users, and for everyone
else. There’s no flag you can set to detect if a site visitor is also a
screen reader user that can be used to then unlock content. And given the
horrible things being done with technology just in the last year alone,
being able to detect screen readers is technology that should never exist.

The amount of time It takes to maintain this is not something I can do for
free and so I’m asking, as an alternative to charging premium prices for
this documentation, for donations in order to keep this material free
to the WordPress community in general and people who use screen readers in
particular. Your financial assistance will ensure that each WordPress
administration screen is properly documented for people who use screen
readers, and that each post is updated when a change to WordPress requires
it. Every donation helps, and there are some sponsorship opportunities as

In exchange for making this possible, the generosity of sponsors will be
acknowledged with the name, logo, and a link to their flagship product
several times in each post.

Personal Info

Donation Total: $5.00

The Audio Widget

From your widgets screen, with accessibility mode activated, navigate to the heading labeled “Audio”. Press the up-arrow key once until you encounter a link labeled “Add audio,” and then press enter on that. On the next screen, navigate to the heading labeled “Widget Audio,” or press your screen reader’s shortcut key for navigating to an edit field specifically, or a form control in general, to navigate to the “title” field for this widget. Using the shortcut key to navigate to an edit field specifically will be quicker, because if you navigate to form controls in general, you’ll have to move past the “expand/collapse menu”, “help”, and “screen options” buttons.

Once you’ve navigated to the “title” field, enter a title. If you decide that you don’t want a title for this instance of the audio widget, leave it blank. If you decide to leave the title blank, your audio widget will not have any heading associated with it. This can impair your site’s useability for some users, so if your audio widget contains a piece of content you’d rather your users not skip, consider giving it an enticing title that will grab attention and interest your users in exploring your audio content.

Directly below the “title” field, you’ll find a message that says “No audio selected”. This message will disappear once you’ve selected an audio file for the widget. Beneath the message, you’ll find a button labeled “Add Audio.” Press enter on this, and the fun begins.

Once you press enter on the “Add Audio” button, focus moves to the media modal. This modal appears at the bottom of the document object model, which means it appears after the “Thank you for creating with WordPress” message. Once you’ve navigated into the modal, the first thing you’ll find is the “Close media pannel” button. If you press enter on this, the media modal closes, and focus moves back to the “Add Audio” button. Press the “Add Audio” button again to re-open the modal if you’ve accidentally closed it.

Directly below the “Close media pannel” button, you’ll find two links:

  • “Add audio”, which is selected by default, and
  • “Insert from URL”, which you can select by pressing enter if you don’t want to or can’t host the media yourself, and you want to insert it into the widget from another source.

Next, you’ll find a heading at level one with the text” “Add audio”. This text will change to “Insert from URL” if that option is selected. Directly beneath the level-one heading, you’ll find two links:

  • Upload files, and
  • Media library, which is selected by default.

Below these two links, you’ll find a combo box that allows you to filter media by the date it was uploaded to your media library, and the default value is “All dates”. Below the date combo box, you’ll find a search form you can use to search for media. If you leave the search field blank, you’ll see a list of all audio you’ve uploaded to your site, shown according to filename. Each filename is a checkbox. Once you check the filename you want to insert, you’ll be dropped into browse/forms mode, and your screen reader will announce the URL of the file you’re inserting. The field you’re being dropped into is the search field. If you press tab, you’ll be able to navigate through the list of all the audio you’ve uploaded, and you’ll hear a message letting you know which filename you’ve selected, and that you can deselect it. Pressing tab again, you’ll hear “filename checkbox checked deselect button”, where “filename” is the name of the file.

We interrupt this important program to bring you a message of gladness and sincere thanks.

Wait, did you say we can select previously uploaded media?

Yes. You read that correctly. If you’ve already uploaded any kind of media to your WordPress installation, you can now select media you’ve already uploaded to be inserted into your widget, instead of having to re-upload the media again if you want to use it, and you can check and uncheck boxes without being in browse mode. For a while, you could only do this if you were using Jaws for Windows. If you were a VoiceOver or NVDA user, or you used another screen reader altogether, you had to switch to using Jaws for Windows in order to work with the media modal. Switching back and forth between screen readers is nothing new. People who use screen readers do this all the time. Switching back and forth while you’re in the middle of a task like adding content to your website is particularly frustrating though, and for some of us is a major interruption. I can’t speak for anyone else, but I’m extremely happy about the fact that this is no longer necessary when I’m adding media in WordPress. Happy as in jumping up and down like a kid at Christmas. The media modal has been a huge bugbear for the WordPress Accessibility Team, so much so that several of us have given up on it and have been just hoping that it would be completely eliminated. For me personally, this part of editing and creating WordPress sites is the only part I’ve hated. Now that I can do something as simple as check boxes to select already-uploaded media while using my favorite screen reader, I hate this process a lot less.

OK, we now return you to your regularly-scheduled program.

Once you’ve selected the file you want to insert, press your screen reader’s shortcut key to navigate to the next edit field. The first one you’ll find in this group is a read-only field listing the URL of the file. Next, you’ll find a field where you can change the title of the file. This doesn’t change the filename on the server, but it does change the title the media is stored with in your database. Once you’re done with the title, you can press tab and fill in the artist, album, caption, and description. All of this information is optional, and you can choose to do nothing with these fields. Beneath the “Description” field, you’ll find a button labeled “Add to widget”. Pressing this will add the audio you’ve selected to your widget. You can also upload new audio directly from this screen, and follow the same insertion proceedure. Once this is done, you’ll select a sidebar for the widget as well as its position, as with any other widget. The media modal will close once you’ve made your selection and inserted your media, and you’ll be back where you started. However, the button labelled “Add Audio” now has a label of “Edit Audio”, and the “No audio selected” message is replaced by a player you can use to preview your audio selection.

To remove the audio you’ve chosen, press enter on the “Edit audio” button. The media modal will re-open, and your focus will move to the “Close media pannel” button. Below this is a link labelled “Cancel edit.” This is followed by a link labelled “Audio details,” and this is selected by default. So the heading at level one on this page contains the text: “Audio details.” Directly below the “Audio details” heading is another player you can use to preview your audio, followed by an edit field containing the audio file’s URL which you can edit, and a button labelled “Remove audio source.” Pressing this button will remove your audio from the widget and return you to the “Add audio” button, with the message “No audio selected” above it.

Below the “Remove audio source” button, you’ll find a prompt advising you to add alternative sources for maximum HTML 5 playback. This is because not all browsers support every file format, and so for the most coverage, you either need to use a file format they all support, (like Mp3), or if you choose to use a file format only supported by some browsers, you can add alternate formats for the rest. To add an alternative format, press enter on the button below the alternative format prompt. This button is labeled “Ogg”, but once you’ve pressed enter on this and moved to the next screen, you can choose any format WordPress supports. If WordPress doesn’t support a particular format, you won’t see files with that extension when you’re either browsing through your media library or uploading a file.

When “Insert from URL” is selected, the “Add media” pannel becomes much simpler, at least for audio. You’re given a field to input a URL to an audio file, and an “Add to widget” button. You’ll still need to make sure you link to a file format supported by WordPress, and to keep things simple, I’ll suggest again that you stick to mp3, since everyone supports it. You do not have the opportunity to add any meta data to your audio if you insert from URL.

The Image and Video Widgets

To add an image or video widget in WordPress, you’ll follow the same process as you followed to add the audio widget. The differences will be the file format you can choose from, which will differ for both image and video, and the types of meta data you’ll enter for the image or video will be different: Alternative text for example instead of artist. With the image widget, you also have the ability to link the image to nothing, directly to the media file, to the image’s attachment page so people can view all the details of the image, or to a custom URL. These options are contained in a combo box. You’ll also be able to choose an image size: Small, medium, medium-large, and large. The specifics of each size are dictated by your theme, and when you upload images to your media library, WordPress generates all necessary sizes so that different sizes can be served to different browsers depending on screen size. Mobile devices get a smaller image size, for example. When inserting an image from a URL, you have the option to link to the image itself, a custom URL, or no URL at all. On this screen, these options are buttons and not a combo box. When inserting video from a URL, you can insert from any of the providers WordPress supports, including Youtube. This means that you can host your videos on Youtube, (as long as you follow their content guidelines), and have the player show up on your site, without having to work directly with embed code.

Once you’re done editing your image or video details, press enter on the “Add to widget” button, and the media modal will close. You can then choose the sidebar for the widget and save it.

The Gallery Widget

With WordPress’s gallery widget, you’ll add images just as you would for the single image widget, and you’ll edit each image’s details before you insert it into the gallery. As you’re adding images and editing details, WordPress will let you know how many images you’ve selected with a prompt that appears just below the “description” field for the image you’re editing. Directly below this prompt, you’l find a button labeled “Edit selection”, which you can use to remove images you’ve already selected. To clear the entire selection, press enter on the button labeled “Clear” just beneath the button labeled “Edit selection”. Once you’re done adding all your images, you’ll insert the whole gallery into the widget, and then choose its sidebar as usual.

Help Keep This Series Free

$685 of $20,000 raised
Each post in this series takes a significant amount of time to research,
write, and edit. In order to make this effort sustainable, I would need to
charge a minimum of $100 U.S. per month in order to compensate for the time
it takes to write this material and the size of the screen reader users
market, which is around 5% of the total market of people with disabilities. This series benefits the whole WordPress community as we strive to create a
more open and more inclusive internet. The group of people who will benefit from this series the most are also the
least equipped to afford to pay a fee like this to access it. In the United
States, as of 2015, 58% of the blind
community is unemployed, and 29% live below the poverty line. Most of these people live
on a fixed income that is less than $1,000 per month.

Your sponsorship will ensure that everyone who uses screen readers
with WordPress get the same opportunity as those who do not use screen
readers: documentation they can freely use to learn WordPress, similar to
what exists in the WordPress Codex for mouse users.

This content has to stay free for screen reader users, and for everyone
else. There’s no flag you can set to detect if a site visitor is also a
screen reader user that can be used to then unlock content. And given the
horrible things being done with technology just in the last year alone,
being able to detect screen readers is technology that should never exist.

The amount of time It takes to maintain this is not something I can do for
free and so I’m asking, as an alternative to charging premium prices for
this documentation, for donations in order to keep this material free
to the WordPress community in general and people who use screen readers in
particular. Your financial assistance will ensure that each WordPress
administration screen is properly documented for people who use screen
readers, and that each post is updated when a change to WordPress requires
it. Every donation helps, and there are some sponsorship opportunities as

In exchange for making this possible, the generosity of sponsors will be
acknowledged with the name, logo, and a link to their flagship product
several times in each post.

Personal Info

Donation Total: $5.00

I have no idea who exactly is responsible for the fixes to NVDA and WordPress that produced the alignment of stars which allows people who use screen readers to use already-uploaded media when adding widgets or content within posts. Maybe these changes are tiny in the grand scheme of both projects, and whoever made them is thinking they’re not very impactful. Spoiler alert: They’re huge. I have a feeling I know who made the changes in WordPress. If I’m wrong, please feel free to correct me. But if it’s who I think it is, Andria, I owe you at least one drink if we ever meet in person. On the NVDA side, I’ve searched the 2017.4 issues, and I’m not coming up with anything. All I know is this wasn’t possible with 2017.3 when I was writing the original widgets tutorial. That’s part of the reason why this content isn’t part of that. I sent a direct message to one NVDA regular contributor asking about this, and I haven’t heard back. So whoever you are on the NVDA side, thank you for whatever you did. You’ve helped make my life a whole lot easier, and, (along with those who work on making WordPress more accessible), opened up the possibility for me to do at least two things. First, I can haz photoblog now yay. Second, when I’m building sites for clients, I now have a choice to decide whether or not to hire someone else to handle the media portion. So, whoever you are, a thousand thanks, and if we ever happen to meet in person, I also owe you at least one drink.

Everyone else, you can now start adding media to your sites now without a ton of frustration and anger. Go forth and make your sites rich and pretty.

Thoughts On “Gutenberg and the WordPress of Tomorrow”


I’ve been waiting for this talk to go up on WordPress TV because I missed it when Morten first delivered it at WordCamp US. It’s no secret that I have a hate-hate relationship with WYSIWYG (What-You-See-Is-What-You-Get” editors for the web. Part of that is because I think if people are going to build websites, then they should learn foundational web technologies deeply. Part of that is also because literally every single one of these editors, when placed in a web context, has been completely inaccessible. I’m including page builders in this, because the problem they’re trying to solve is the “What-You-See-Is-What-You-Get” thing, but for people who aren’t developers. I started working with things on the web back in 1998. That’s a long time ago. Every single WYSIWYG editor and page builder I’ve encountered from that day to this has proven me right. Geocities page builder. Yahoo page builder. The website wizard that ships with Cpanel. Squarespace. Strikingly. Medium. Beaver Builder. Visual Composer. Wix, (except for that one time they borrowed code from the WordPress.com app). Every single one of these, along with every other similar thing I haven’t named, has been or is unuseable if you use assistive technology, or even just don’t use a mouse. When Gutenberg first came on the scene as a plugin in beta, I tested it twice, and was absolutely certain that it would be just like all the others. I kept hearing, “We’re going to make it accessible,” to which my response, (at least internally), was “Sure you are. Just like all the others who talked about how important accessibility is, only to leave it out when it came to the editor/page builder.” My initial tests cemented that response. I wasn’t alone when it came to being highly skeptical of Gutenberg and accessibility.

And then, things started changing. The Gutenberg developers were serious about making sure Gutenberg is accessible to everyone, with the best example so far being the demmo at this year’s State of the Word highlighting what I’ll refer to as color contrast guardrails. That’s not cosmetic accessibility. It’s not something like “we added some read-aloud kind of feature and a font resizer and: Magic! We haz accessibility now!” The Gutenberg experience still isn’t great when it comes to accessibility. There’s still a lot of work to be done. But Gutenberg is proving me wrong with regard to WYSIWYG editors, and I’ve never been more happy or more proud to be wrong in my life. This is actually happening. There’s actually going to be an accessible visual editor. People with disabilities are going to get to play on the same playground as everyone else is for once. We finally get to play in a world that everyone else has played in for the last twenty years, and this makes Gutenberg genuinely exciting. It’s vital though that Gutenberg is properly documented for screen reader users. First, WordPress has to establish trust with a group of people who have years or even decades of experience of being burned by these kinds of editors. That may not be fair to WordPress, but if WordPress is entering this space, it’s now in the position of having to clear away the baggage left behind by everyone else, and people who use screen readers have very long memmories when it comes to these sorts of things. Merely saying “Our thing is accessible” is not enough. I didn’t believe accessibility was going to be taken seriously, and that’s despite being a member of the WordPress Accessibility Team and having a bias in favor of WordPress for which I’m famous. Convincing anyone else that we mean it when we say this is useable by everyone regardless of whether or not assistive technology is involved is going to take work, and part of that work is going to be convincing people with disabilities to make that leap while trusting that what’s on the other side isn’t going to be the same old song and dance that’s gone on for the last twenty years. Second, the steps that everyone else has been gradually making over the last twenty years with regard to WYSIWYG editors and page builders are all going to be combined into one giant leap for people who use screen readers, because the workaround when you can’t use a visual editor is to rely on a text-based one, whether that’s copying and pasting from a text file or switching the TinyMCE editor to text mode in WordPress. People who use screen readers are now going to have to integrate all the visual concepts, along with the technical aspect of controlling them. We’ve been able to avoid doing that, unless we’re web developers, at which point we then start wrestling with CSS. But if you’re not a web developer and you’re focusing on using software like this, until Gutenberg, you’ve been able to almost completely avoid dealing with visuals, unless you’re doing something like choosing a theme or adding images to a post or page. Otherwise, it’s text whenever possible. Changing the status quo this much, without documentation to aid the transition for people who use screen readers, ensures that as a user group, we are not likely to make the leap, unless we have a pressing need to do so. As a whole, we’ll just switch to a different platform with less advanced editing, or, if we don’t already have websites, just not have a website at all and use Twitter or Facebook to create content on the web. Personally, I’m willing to make the leap, and help others do the same. I want everyone to participate in the WordPress of tomorrow, to continue to have the ability to choose whether or not to own their own data, ETC. But I have a vested interest in WordPress. I want everyone who wants to use WordPress to be able to keep up with the changes that are coming without having to make a choice to add content to their websites that’s based on “How much mental and emotional energy am I going to have to put into this?” That’s not going to be possible unless there is proper documentation to go along with the software.

Some Thoughts On “Managing Accessible Content on Thousands of Sites”

Jeremy Felt gave the below talk at this year’s WordCamp US, in which he details how just over a year ago, Washington State University received a complaint through the Office of Civil Rights that some of their web pages were not accessible, and what they’re doing to resolve the complaint. I have some thoughts that I’ll share after the video.

Download “Managing accessible content on thousands of sites” directly.
There are a few things that stood out for me in this talk. First, the transparency. I’m glad to see some universities detailing how they’re resolving OCR complaints, because it shows universities who are in the process of figuring out how to resolve complaints a path forward. The talk also demonstrates that, if a university with five million URLs to handle can get the process going, so can universities with smaller web footprints, and even K-12 schools with tiny budgets. Washington State has even made their tools and related documentation freely available. Free as in other universities can download them and use them without spending budget. I’m sure other universities have also made tools available, but this is a pretty extensive collection, and they’re not even all WordPress. So if a school isn’t using WordPress, there’s still something here they can use. Not that schools had any excuse before now to use to suport waiting to make their websites accessible, because the laws governing website accessibility for schools are not new, and there have been a metric ton of OCR complaints already. Now, not only do schools have no excuses, they even have free resources they can deploy so they don’t have to create them on their own. I’m going to be spreading this talk and the linked resources as far and wide as possible.

Mindmapping Is A Great Way To Generate Blog Posts Quickly, And Now You Can Mindmap Accessibly

My friend and colleague Bob Dunn wrote a post on generating blog post content by mindmapping a couple years ago, and when I first saw the post, and read through his tips and techniques, I have to admit I became slightly jealous. OK, very jealous. I couldn’t figure out how to adapt the strategy to make creating mindmaps accessible, and so I believed this was something I just couldn’t use and that I’d have to stick to other strategies for creating blog content. To add to the jealousy, Bob is the king of CoSchedule, which means he’s really great at taking his old content, writing new headlines for it, and then sharing it multiple times on social media. This was also not helping my jealousy problem.

This morning as I was browsing through my personal Twitter feed, I came across a post on Blind Bargains in which Tangela Mahaffey reviews a mindmapping app called MindNode 5, available on iOS. Because this is Blind Bargains, accessibility plays a huge role in whether or not something gets reviewed or even posted. If it’s not at least reasonably useable by blind people, Blind Bargains doesn’t cover it.

When I encountered this link in my Twitter feed, I was thrilled. It meant that I would be able to take advantage of a blogging technique that I had reluctantly set aside, and it meant that I could start freely sharing Bob’s post on mindmapping because there’s now an accessible way to do it.

The Blind Bargains post reviews MindNode 5 extensively, going through each step of the process to set up and use the app while using VoiceOver for iOS. If you’re a blogger, or if you want to blog, I strongly encourage you to open Bob’s post in one tab, and Tangela’s post in a second tab. Then, start fitting Bob’s techniques into this app. Mindnode 5 is definitely on my wishlist of apps for iOS, and I can’t wait to get started using it.

Custom Entry Message Boxes: Some Quick Accessibility Considerations

There’s a quick tutorial on custom entry message boxes on the StudipPress blog, and because I think this could be a useful addition to a site for things like affiliate disclosures, I’d like to offer some accessibility considerations.

Look out for color contrast

When adding the example CSS to your theme, make sure the colors for links inside the message, the bottom border color, and the various message color schemes don’t introduce color contrast issues into your theme. You’ll want to make sure there’s appropriate contrast between the message foreground and background, as well as apropriate contrast between the message and the surrounding text. You may also want to include a style guide somewhere on your site explaining the significance of each colored message, and add that link to your custom message.

Make sure the importance of the message isn’t communicated by color alone

When adding your custom entry messages, make sure that the importance of the message isn’t communicated by color alone. You can accomplish this by prefacing each message type with a word or series of words indicating its importance: “Important”, or “very important” or “urgent”, for example. You’ll want to make sure you don’t make these indicators visible to just people who use screen readers, since people who live with color blindness or cognitive disabilities also need to know the information you’re alerting everyone else to.

Custom aentry message boxes can be a useful addition to some types of websites. If you’ve never planned for accessibility before, they can be a great place to start developing that habit, since they’re a simple customization. It doesn’t matter if the rest of your site is accessible at this point. These messages are a great place to start making improvements, and to borrow from the philosophy of Breslov Hasidism, one accessibility improvement paves the way to another, and you should make as many accessibility improvements as you can, even if you can’t improve everything at once. Finally,

The work is not for you to finish nor are you free to desist from it.

Mishnah, Pirkei Avot (Maxims of the Sages) 2:15-16

In Defense of the #a11y Hashtag

There are some accessibility issues you could call evergreen. One of them is whether we should use the #a11y or #accessibility hashtag when spreading the good word on the social medias. Mosen Consulting shared a post in which Mr. Mosen holds that

… the use of the #A11Y numeronym, a hashtag sometimes used on Twitter to group accessibility-related tweets together, lessens the impact of tweets on a subject that is critical to the independence of many of us.

I would like to respectfully disagree and challenge this viewpoint, in favor of the #a11y hashtag.

Firstly, hashtags may have started out as a way to conveniently group social media posts, but they quickly became a marketing tool. At this point, they’re about branding. The word “Accessibility” means different things in different contexts. So those of us concerned about accessibility as it pertains to making things useable by people with disabilities need to be able to distinguish between “accessibility” as a general term and “Accessibility” narrowly defined in the specific way we’re concerned with. The #accessibility hashtag doesn’t do that. The #a11y tag does.

Secondly, people more often than not interact with social media on their phones. That’s one of the reasons numeronyms became a tool among various groups of professionals on social media. Other examples include #i18n (for internationalization), #l10N (for localization), and conference names beginning with just their initials in a lot of cases instead of the entire name. Previous character limits also played a role in this. But between convenience and previously-existent character limits, #a11y wins the game whereas #accessibility creates a barrier to entry.

Thirdly, the #accessibility hashtag might have been able to gain a hold if it had been campaigned for back in 2010 or 2011 when this all started. But by 2013, (when Mosen Consulting first raised the issue), #a11y was already entrenched. That’s only a three-year difference, but three years in social media land is like thirty years everywhere else. At this point, using #accessibility instead of #a11y would be separating ourselves from the community of practice, and this community is small enough that it really can’t afford that kind of split.

If it’s newby confusion you’re worried about, people who are new to accessibility are going to be confused no matter which hashtag is used. Whether you explain what a numeronym is, or whether you explain that “Accessibility” has a specific meaning when it comes to people with disabilities that doesn’t have anything to do with the other meanins, you’re still explaining.

Finally, dropping the #a11y hashtag would negatively effect other related hashtags, like #gbla11y. This one would, (at best), need to then become #GBAccessibility, or #GBAccessibilityAwarenessDay. Either of these are very long to type on a mobile device.

As long as we’re talking about confusion among terms, I think we ought to drop the term “Accessibility” altogether in favor of inclusive design. Inclusive design goes further when it comes to addressing the needs of everyone, including people with disabilities, and there’s no ambiguity around the term. We could even go with the #iDesign hashtag. As long as we’re keeping “Accessibility” though, I think it’s best not to further muddy the waters with what I would respectfully call a localized version of the “tabs versus spaces” argument.

WordPress Widgets: A Comprehensive Guide

To one extent or another, widgets are part of most WordPress sites. They’re typically added and rearranged by dragging them around and then dropping them where you want through either the “Widgets” screen or the Customizer in the administration side of your WordPress installation. Along with the drag-and-drop interfaces in both the main “Widgets” screen and the WordPress customizer, there’s also an accessibility mode for controlling WordPress widgets that isn’t very well documented.

In this guide, I’ll give you a brief history of how WordPress widgets came to be, document the “Widgets” screen’s accessibility mode, show you how to add and arrange widgets on your site, provide some tips on widget placement when you don’t have perfect vision, and discuss the fundamental shift that is coming to WordPress and how that will effect WordPress widgets.

The What and Why of WordPress Widgets

WordPress widgets are self-contained areas of a web page that perform a specific function. They were created to allow WordPress.com users to customize their sidebars without touching a line of code. After an overwhelmingly positive response by WordPress.com users, WordPress widgets became a WordPress plugin. Widgets became a core WordPress feature in version 2.2.

Two years after WordPress widgets were introduced to core, accessibility mode was added so that keyboard users and people with disabilities could control the widgets on their sites. Accessibility Mode was one of the WordPress project’s first forrays into web accessibility, having been added to core about three years before there was a dedicated accessibility team.

Although they were originally developed to help customize just the sidebar of a theme, WordPress widgets are now used to build the home pages of many premium as well as free WordPress themes. They are an indespensible tool for building WordPress websites, and you can get pretty far without knowing any code by using them. So let’s go through how to add and configure them accessibly, step by step.

Activate accessibility mode

From your WordPress dashboard, select the “Appearance” submenu, and within that submenu, select “Widgets”. Once you’re on the “Widgets” screen, expand the “Screen Options” tab by pressing enter on it. Press enter on the “Enable Accessibility Mode” link. Collapse the “Screen Options” tab by pressing enter on it again, and you’ll return to the mane “Widgets” screen.

An Overview of the Widgets Screen

When you enable “Accessibility Mode,” the appearance of the “Widgets” screen changes significantly. The first thing you’ll encounter once you’re in the main content area of the screen is a heading at level one that says: “Widgets”. Directly under the “Widgets” heading is a link to manage them in the customizer with live preview. Ignore that for now. We’ll discuss using the Customizer in a later post. Below this link, you’ll find any administration notices currently visible on your dashboard.

Next, you’ll find a heading at level two containing the text: “Available Widgets”. Directly below this, you’ll find a link with the text: “Add”, folowed by the widget title. All widget titles on this screen are contained in headings at level two, and below each title is a brief description of what the widget does.

How many widgets?

The number of widgets you have on this screen depends on the widgets your active theme and active plugins have added. Both themes and plugins often add their own widgets since they’re so integral to customizing WordPress sites. Each widget will have its own configuration options on the add-widget screen.

Below all the available widgets, you’ll find a heading at level two with the text: “Inactive widgets”. This section stores any widgets you’ve previously used, in case you want to resume using them along with the configurations you’ve set. There’s also a “clear inactive widgets” button you can use to empty this section. Clearing inactive widgets deletes them permanently from this section along with their configurations, so if you visit this section after you’ve cleared it and find you need to use one of the widgets you previously stored here again, you’ll need to go through the process of re-adding and reconfiguring it. Each widget title in this section is wrapped in a heading at level three.

Below the “Inactive Widgets” section, you’ll find each of your theme’s widgetized areas with its title wrapped in a heading at level two. Above each widget title in this section, you’ll find a link with the text: “Edit”, followed by the widget title. When you press enter on any “Edit” link, you’ll be taken to the widgets configuration screen where you can make and save changes. The number of widgetized areas depends exclusively on your theme. The name given to any widgetized area also acts as a brief description of that area. Below each “edit” link, you’ll find the widget title wrapped in a heading at level three.

WordPress’s Default Widgets and Widget Configuration

Aside from the widgets provided by your active theme and plugins, WordPress comes packaged with several default widgets. I’ve listed all of the default widgets below, and, (because I’ve been around the WordPress block a time or two), any experience and/or opinions I may have about each one.

  • Akismet Widget: Display the number of spam comments Akismet has caught. In my experience, this widget doesn’t have a practical use. Displaying the number of spam comments caught is merely a vanity metric, and is not likely to increase the trust of your site’s visitors.
  • Archives: A monthly archive of your site’s Posts. This widget is useful if you run a blog with a lot of excellent content that people may want to re-visit.
  • Audio: Allows you to easily display an audio player without knowing HTML. This widget is useful if you’re a musician and you want to showcase tracks you may have for sale.
  • Calendar: A calendar of your site’s posts, in a data table. In my experience, this widget also has no practical use, since a site’s visitors won’t typically browse a site’s posts by month.
  • Categories: A list of links to all of your site’s categories, (excluding any attached to custom post types), or a dropdown, (combo box) of all of your site categories, (excluding any attached to custom post types).
  • Custom HTML: Allows you to add text marked up with HTML. This widget is infinitely useful, in my opinion. It often forms the backbone of the text on home pages, and is also useful for things like displaying banners, badges, one-time advertisements or advertisements controled by a third party, site announcements that don’t merit their own blog post, the list of possibilities for this widget is close to endless.
  • Custom Menu: Allows you to add a WordPress menu to areas of your site without those areas needing to be defined as menu locations by your theme. This widget is useful if your theme is stingy about navigation menu sections.
  • Gallery: Provides a graphical user interface for adding a gallery of images to a widgetized area on your site.
  • Image: Provides a graphical user interface for adding a single image to a widgetized area, including any image attributes such as alternative text and captions.
  • Meta: Login, RSS, & WordPress.org links. In my experience, this widget is also useless in practical terms. Most sites will not want to display links back to WordPress.org, and I’m not a fan of displaying a log-in link on the front-facing portion of a site for anyone to be tempted by. This last bit could just be me having a get-off-my-lawn moment.
  • Pages: A list of your site’s pages. This widget could be useful, although it displays a list of every page on a site, and I recommend adding important pages to your navigation menu instead.
  • Recent Comments: Your site’s most recent comments. This widget is useful if you run a site that gets a lot of user engagement in the form of comments, typically large blogs.
  • Recent posts: Your site’s most recent posts. This widget is useful if you’re using a static front page as your home page, but you want to highlight recent posts in a side bar.
  • RSS: Entries from any RSS or Atom feed. This widget can be useful if you run more than one site and want to quickly display content from that site on another site.
  • Search: A search form for your site.
  • Tag Cloud: A cloud of your most used tags.
  • Text: Allows you to add any text to a widgetized area using the standard WordPress content editor. The aim of this widget is to make adding arbitrary text easier for those who don’t know HTML. The custom HTML widget was added after enough of us expressed our displeasure at having our favorite widget contaminated with a WYSIWYG editor. This widget also supports adding an image to a text widget, using the “insert image” button in the editor tool bar.
  • Video: Displays a video from the media library or from YouTube, Vimeo, or another provider.

Common Configurations Among WordPress Widgets

Every widget has configuration options specific to it, but there are parts of every widget configuration that are the same no matter which one you’re adding or editing. Each screen will ask you to choose the following:

  • Widgetized area: Labeled as “Sidebar”, this refers to any widgetized area of your theme, including dynamically generated pages.
  • Position: The position of the widget you’re adding within the widgetized area. Each area commonly has two positions, although I’ve seen situations where there are more than two.

All the widgetized areas and their positions are displayed within a table. Select the radio button for your preferred area and choose the position of the widget from the combo box below the radio button you’ve selected. Once you’ve chosen the widgetized area and the widget’s position within that area, save your configuration choices by pressing the “save” button. If you’re editing a widget, and you want to delete it, press the delete button without changing any configuration options instead. Your deleted widgets will then appear within the “Inactive Widgets” section until you clear the section of its contents. After you’ve added or edited your widgets, you’ll be redirected back to the widgets screen after you press the “save” or “delete” buttons. If you decide while editing or adding that you’ve changed your mind about the widget, there’s a link labeled “Cancel” directly above the “Save” button. Press enter on that and you’ll be redirected back to the widgets screen and your changes will not be saved.

Some Tips On WordPress Widget Placement

When adding widgets to your site, there are some things you’ll want to keep in mind as a visually-impaired or blind person. Firstly, not only does your theme define what widgetized areas are available, it may also style specific widgets. Alternatively, a theme’s CSS may need to be modified to accommodate a widget the theme has no styling for.

Secondly, widgetized areas themselves will be styled, and this will determine which widgets may be suitable for a particular area, even if the theme doesn’t require specific styling for the widget. It can be helpful to read through your active theme’s CSS to get a sense of what’s going on visually. This is why I prefer the Genesis framework and its child themes when building sites for myself or for clients. The CSS is very well-organized and well-commented, which makes it easy to read.

If you’re not sure about how a widget is going to look with your theme, ask for help. The help you need could be as simple as someone advising you on a more suitable area for the widget, or as complicated as someone customizing your theme for you. Be aware that the former can be readily had for free, while the latter will cost you. Any investment on your part will be necessary though if you’re selling products or providing services to the public. A well-designed website is just as important as the clothes you wear to a job interview. If it’s your personal blog and you want your sighted friends to read what you’re writing, then design also matters, if for no other reason than avoiding a poor user experience for your sighted visitors. It doesn’t have to be anything fancy. It just needs not to be an eyesore. Finally, when you change themes, you’ll need to go back in and edit your widget placement. The new theme you’ve chosen may have different widgetized areas, and/or the widgets you used with your old theme may be part of the theme itself. If they’re part of the theme, they’ll disappear from your available widgets once you deactivate the theme by switching to the new one.

Change is coming to WordPress, and this will effect WordPress widgets

Before wrapping up this guide, I want to talk a bit about the changes coming to WordPress in the near future, because they will have an effect on WordPress widgets. The changes I’m referring to are code named Gutenberg, and the goal of the project is to change the way content is created in or added to WordPress. This includes widgets. The aim of the Gutenberg project with regard to widgets is to make them portable, meaning that they’re no longer dependent on widgetized areas, and can be added to anywhere on a site. This will help site owners more easily create dynamic pages, for example. In the future, it will also mean that wordPress doesn’t need to maintain three separate interfaces for controlling widgets: The customizer, the main widgets screen, and accessibility mode. It will mean that site owners wil be able to add widgets to their sites accessibly while taking advantage of the same interface that everyone else gets to use, thus eliminating the separate-but-equal status of assistive technology users. Widgets will become portable, so site owners won’t necessarily need to worry about reconfiguring widgets when they change themes. All of this is in flux, and is not slated to be released until it’s ready. There are accessibility kinks still being worked out. But Gutenberg promises to be a better experience for everyone, and despite my current concerns, I’m fully on board with the idea. It will, however, mean some adjustment for those who have been using WordPress for a while. The content creation experience, (including editing and controlling widgets), is going to become richer, and initially there will be some discomfort on the part of those who are used to the old way of doing things. Because those of us who are blind or visually impaired have never had complete access to the way the rest of the world does things when it comes to creating sites, I think the jump will be initially hard to make, because we’re going to need to get comfortable to a whole new set of concepts we’ve never experienced before. But I’m looking forward to the challenge, and I’ll be updating this guide so that you’ll be able to navigate them as well.

Widgets have been a staple of customizing WordPress sites for a long time now. This guide should help you more confidently experiment with them to make your site your own creation. There are as many widgets as there are WordPress plugins and themes, so there’s a lot of variety for you to explore when customizing your site, all without touching any code. Go forth and build cool things.

Gleanings From Mozilla Festival 2017 With Transcriptions Of Screenshotted Text

Conferences with social media hashtags are great, because those hashtags mean that you can still glean from them even if you can’t attend. It can also be overwhelming when there’s so much goodness happening on a conference hashtag that you want to share everything you find. There’s also the problem of all the great content being generated on one social network essentially being locked into that network as long as we’re only sharing it on that network. So I’ve decided to start sharing the cool stuff I find from various conferences as blog posts. That way everyone can take advantage of it whether they’re on a particular social network or not, and I can avoid filling up people’s timelines with reposts. I can also take the liberty of providing screenshotted text in text form so that everyone can read it.

Here are my gleanings from MozFest. MozFest was born in Barcelona, Spain, in 2010. Originally named “Drumbeat,” the festival convened a community of people dedicated to learning, freedom and the open Web. Each year MozFest centers around a particular theme, and this year’s is the health of the web as a whole, (spoiler alert: It’s not good), and how we as contributors to the web can improve it. Everyone is a contributor to the health of the web, not just the people who make the software that powers it or allows people to access it or allows people to easily create content for it. This year, MozFest consisted of nine floors of talks, workshops and exhibits. Once the speaker talks are available somewhere other than Facebook Live, I’ll share some of those as well, in separate posts.

All of the content I’m sharing is publicly available within the constraints of Twitter or Facebook. I’m sharing it in the order I read it. I’ve also transcribed any screenshots I’ve shared. I’ve shared directly from the social networks, so you have the opportunity to share on your own timelines if you want, without copying and pasting. Enjoy.

Meet this year’s Mozilla Festival speakers.

Only 20% of the world, primarily white folks, are
editing 80% of Wikipedia’s content—that’s kind of
telling. Together, we realised that most of our
collective understanding of the world is still being
written by a minority.


What we need are companies that are
not advertising platforms, to make
browsers — the basic tech of the net.

Mishi Choudhary

Have a security policy. You can think of it like the
things you are already doing to be digitally safe.
Maybe this is where it all begins.

Matt Mitchell

Digital inequality is just as bad
as any inequality.

–Alan Knott-Craig

To be digitally safe as an organisation, you need
to think of a checklist. It is a matter of time until
something happens… This checklist saves
people. If anything happens, you know what to

–Matt Mitchell

Making a healthy
Internet is not a spectator

–Mark Surman

More products include software inside them to be
updated over time, but practically the support to these
products ends a lot sooner than the companies are
willing to provide a warranty for the product—which is
probably insane.

–Ugo Vallauri

“I think all of us are feeling [an] urgency….You have
instability—I have been thinking about the need for
knowledge, the need for inclusion, the need for the
power and potential of the movement.

–Ryan Merkley

The Trump Administration thinks that letting some
telecom companies treating some content more
favourably than others is a good thing. Think about
how these companies treat it already. It could not be
any worse

–Ashley Black

You’ll now detox one of the browsers you use on your computer (you’ll clean up your mobile browsers
later, on Day 5). By the end of todays detox, you should be blocking a lot more information from trackers, and this in turn should make your browser less unique – since there’s less information to form a
The devil’s in the default “Privacy Settings”
No browser’s default privacy settings are actually private by default: most store cookies, as well as
your browsing history, webform entries and other information-which can then get shared.
But Chrome, Firefox and Safari all offer a special “Private” or “Incognito” browsing mode, set to
automatically delete your browsing history, cookies, temporary files and webform entries every
time you close the browser. Note: your bookmarks and downloads are not deleted.
Try it out:
1. Open your browser (Firefox, Chrome or Safari) and go to File -• New Private/incognito Window
(depending on the browser).
2. To set Private Browsing permanently in Firefox or Safari, go to:
Firefox: menu>Preferences>Privacy>settings for history

Note on this transcribed screenshot: The last bit of text at the end is too garbled for me to make out and correct, but the steps listed above are still useful. There will be an online version of the data detox kit coming soon, and as soon as that’s available I’ll link to that instead.


Designing For Inclusion With Media Queries

Inclusive Design 24 (ID24) is happening again on November 16, and I can hardly wait. If you’re not aware of what ID24 is, it’s twenty-four hours of free talks on accessibility and inclusive design. Each talk runs for about an hour, and the entire event lasts for twenty-four hours straight. I told myself I wasn’t going to stay up for twenty-four hours again at the end of the last event, but now that it’s happening again I’m seriously reconsidering that, because it’s so much fun and there’s so much stuff to learn and cool people to engage with using the #id24 hashtag on Twitter.

In anticipation of ID24 happening again, I thought I’d share my favorite web-related talks from past events. The one I’m sharing today is “Designing for Inclusion with Media Queries,” and it was given by Eric Bailey. Eric is a Boston-based user experience designer who helps create straightforward solutions that address a person’s practical, physical, cognitive, and emotional needs using accessible, performant, device-agnostic technology. You can find him on Twitter as @ericwbailey and you can read more about his work at ericwbailey.design.

I’m Participating In The Ultimate Blog Challenge This Month, And I Think You Should Join Me

For me, one of the best parts of the web has always been blogs. They’re an expression of the web as it was meant to be, at least in one aspect. Open and independent. Somehow we all got sucked in by the convenience of social media, and while social media has meant that it’s sometimes easier to stay connected, we’ve traded a lot in exchange for that ease of connection, and most of it isn’t good. But more on that in another post.

What’s a blog challenge?

Put simply, a blog challenge is setting yourself a goal to write a blog post at least once a day for a certain number of days. The one I’m participating in this month is called the Ultimate Blog Challenge, and I’ll be shooting for thirty-one posts in thirty-one days. It starts today, and you still have time to join if you want to participate. Once you sign up, you’ll get an email each day with blogging tips and prompts. You can either use the prompts from the emails, or chart your own path. There’s a Facebook group you can join to share your posts and read posts from others, along with a Twitter hashtag: #blogboost. If you’re participating, make sure to comment on other people’s posts. It’s a great way to build community and relationships, and it’s also part of the rules.

What if I don’t have a blog?

If you don’t have a blog yet, why not start one? It doesn’t matter what platform you use or how technical you are. If you have an old blog, why not dust it off? And you don’t have to write three hundred words every day. It’s perfectly fine to write a short post, or just share a photo with its caption. You could even use the challenge to begin to own your data, or just get a writing habbit going. Microblogs also count.

I’m not sure if there’s a point at which you can’t sign up anymore, so I’ll encourage you to give it some thought, and if you’re going to join, do it as soon as possible. Even if there’s not a closing date for sign-ups, the sooner you join, the less you’ll need to catch up. So give it some thought, and come press publish with the rest of us. It’ll be fun.

Are HTML And CSS Still Valuable On Their Own? Abso-friggin-lutely

There’s a post going around web maker social media that deals with the subject of HTML and CSS being undervalued, to the point that people who only write HTML and CSS, or even people who don’t write JavaScript, have no value in this industry, and how we desperately need to change that mindset. It struc a chord, and I have some related thoughts. Well, more like a related rant, because although this attitude is one that’s being talked about as if it’s new, the truth is it’s not special to JavaScript, but more on that later.

Money quote:

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
Mandy Michael

In case you were wondering, we have a long, long way to go before we get to the point where every single website meets the qualifications I quoted above. We’re not even close. Wanna know why? Crappy HTML, and crappy CSS. That is pretty much what this whole accessibility thing comes down to, at the most basic level. People who use assistive technology can’t use ninety percent of the web because crappy HTML and crappy CSS. You have trouble using your phone to browse the web when it’s sunny out on your back porch because crappy CSS. If you pay me to audit your WordPress theme or plugin, the overwhelming majority of the issues I’m going to flag have to do with the way your PHP and JS are creating HTML and you’re using crappy CSS. Wanna use ARIA for your controls? Guess what it does. Extend HTML. And this isn’t a JavaScript-specific thing. They’re far from the first to be of the opinion that HTML and CSS aren’t important or are less valuable than the latest fad. This idea is almost as old as the web itself. PHP shares this attitude in some quarters. So did every other community building something that was supposed to be the be-all-end-all of creating things on the web. I’d even venture to say that this attitude was prevalent for a very long time in the WordPress space, and the further you get from the inner circle of the WordPress community, (the one percent, if you will), the more prevalent this attitude is. But HTML and CSS are critical to how the entire web works, and unless you learn them to underpin your JS and your PHP or whatever other web technology comes along in the future, we will continue to have a broken web, and it’s only a matter of time before you, personally, have to deal with the consequences in a way that you can’t change by simply changing your surroundings. Seriously, don’t wait till it gets to that point. Learn HTML and CSS properly so that we all have a web to use no matter what the circumstances. Learn HTML and CSS properly so you can build page builders with graphical user interfaces that anyone can use to build things for the web that work for everyone. Don’t shift onto the shoulders of your users the task of playing whack-a-mole to find accessibility problems and then making the extra effort to report them to you in the most diplomatic way possible, because that takes a metric ton of energy and emotional labor, and every single person with a disability should not have to be an accessibility advocate. Don’t continue to foster a situation where there are entire platforms where you can’t build or use a website while using assistive technology, only to then be possibly told that if you want to be able to do so, you might have to vote on it as a feature, and hope you can get enough people together to convince some CEO somewhere that this thing that is part and parcel of how the web was intended to work that he’s now considering an enhancement is something he really should fix on his platform. It’s not enough for only some platforms to be accessible. Every single one of them should be, by default, and getting there requires that anyone who calls themselves a web developer learn HTML and CSS, even if that means you have to stop what you’re doing with the latest sexy thing on the web so you can go back and learn them.

I could probably boil all of this down to “Don’t be a jerk.” But “Learn HTML and CSS” is the one thing that the accessibility community has been saying for years and years and years and years, and if we were to turn this into a drinking game, (every time you have to correct some developer’s HTML or CSS, take a drink), we’d all be dead from alcohol poisoning. And it’s incredibly disheartening to ponder where we might be if everyone who ever built anything for the web had learned its foundational technologies properly. So, go learn HTML and CSS deeply, and quit devaluing these technologies by your words and actions.

The Next Time You’re Thinking About Threading On Twitter, Write A Blog Post Instead

If you spend a lot of time on Twitter, you’re probably familiar with Twitter threads. They show up in your timeline because either someone quotes or retweets someone else’s threaded tweet, or, if you’re lucky, you see all the tweets in the right order because (a) someone takes the time to thread them properly by sending one tweet, and then replying to the original tweet with the rest, and (b) you either follow the threader, or their account is public and you have it on a list, so you see the tweets as they come in. If you’re on Facebook or some other social network, and one of your friends wants you to see the thread, they’ll share one of the tweets from the thread in the hope that you’ll click on it and read it. But Twitter threads are not good for all sorts of reasons, and because I feel rather strongly about the subject, I decided to write a ranticle about it.

Why do people thread in the first place?

People thread on Twitter because Twitter’s 140-character limit is almost never enough when you really need to get something off your chest. Also, Twitter, (including third-party applications), has an incredibly simple posting interface without a lot of distraction involved. The fact that you can use a third-party app on your phone which may have an even simpler posting interface, through which you can fire off tweets at the drop of a hat, makes it even better. When you add up a 140-character limit, plus a really simple posting interface, it’s easy to see why Twitter threads have become as popular as they are.

Still, I would like to discourage you from Twitter threading. In the strongest possible terms.

Threading might be great if you’re the one posting the content. I use the word “might” because whether it’s great for you or not is debatable. But if you’re trying to read it, that’s an entirely different story. For one thing, it takes a lot of time and effort to scroll back through tweets, and that’s assuming you’ve stumbled on the original tweet that started the thread. If not, you’re stuck in the hell that is Twitter’s user experience trying to scroll back through tweets. If someone quotes a tweet in your thread, the thread is now broken, which makes the effort needed to put into reading an entire thread much more involved. It means that you might have to spend more time in Twitter’s horrible user experience hellscape trying to find out where the thread begins because someone quoted in the middle of a thread. Second, since Twitter threads are by their nature chunks of ideas, it’s realy difficult to cite a thread in such a way that keeps all the comments in context. Since tweets are now making up a large part of what gets reported by news outlets of all stripes, that means this has become more important, both for those reporting the news and for those reading it.

Next, there’s the problem of linking to this content. Since each tweet has it’s own link, and that link is based on a user ID, linking to all the pieces of content that make up a thread is somewhat like collecting individual rice grains once you’ve dropped the bag of rice. Not easy. And depending on how many tweets are in the thread, (I’ve seen threads of over 300 of them), a metric ton of work.

Then, there’s the part about how the content you create is yours and not some corporation’s. There are a lot of good ideas floating around Twitter, (and other social networks for that matter), but as long as that content is being posted on Twitter and nowhere else, you don’t own that content. If Twitter decides to change its link structure, that content may be lost.

This is important for people, but it’s also important for businesses. Posting your content on Twitter in the form of a thread, (or really, on any social network), instead of your website means you no longer own that content. It’s like going and setting up a stall at the local flee market and calling it your office. You’ve invested time in creating that content, you should own it. It should have a permanent link that won’t change unless you want it to, and which anyone can link to. Then, you can syndicate that content to Twitter, or Facebook, or anywhere else you like, and even if someone isn’t on any of those networks, (believe it or not, there are people who don’t use social media, and have no desire to start using it), can read and benefit from your content.

But what if I’ve already threaded on Twitter?

Fortunately, there are some tools you can use to collect all the parts of your thread and turn them in to blog post for later linking and enjoyment. Spooler is an excellent choice for converting Twitter threads into blog posts. You can start with the last tweet in a thread, and it will also grab any videos and images you’ve posted to Twitter that are part of the thread. If you find that you’re live-tweeting a talk or something similar, Noter Live is a great option which will, (once you’re done tweeting), allow you to copy all your tweets from the event into one post, along with including the speaker’s Twitter handle if they have one. If it’s the feedback you’re after, you can always enable webmention on your site. Popular web platforms like WordPress and Drupal have plugins to do this, and you can use a service like Bridgy to syndicate your content to the social networks, and then pull in reactions and responses to your own site so you have them all in one place, coupled with the content you created.

While I’m pretty certain this one post isn’t going to stop you from threading tweets, I hope that you’ll consider the people who are reading the content you’re creating, and instead of creating a thread that’s not even enjoyable to read on Twitter, you’ll at least consider turning it into a blog post afterwords.