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.

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.

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.

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.

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.

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.