Accessible WordPress Themes

1 October 2018 by Amanda Rush Leave a Comment

Just a quick test to see if publishing to this Twitter account using my own website works correctly. #indieweb

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

10 August 2017 by Amanda Rush 46 Comments

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.

WordPress, Web Accessibility and Web Development Roundup for December 18-31 2016

31 December 2016 by Amanda Rush Leave a Comment

This one covers a rather long period of time, (see: the holidays), and there’s also a lot of heavy reading in it. Not all of these posts are technically recent, and I’ve made a point of including things that are a bit more out-of-the-way and that aren’t featured on the big sites like Smashing Magazine or CSSTricks. Not that I don’t like those sites. It’s just that I assume that most of us already have their content coming to us through their feeds or social profiles. And, like music, the best content isn’t the stuff that gets released for air play. It’s everything else on the album. Enjoy.

WordPress

Why WordPress removed the underline button from the visual editor.

BobWP on WooCommerce Connect, a neat little plugin I haven’t yet had the chance to play with yet.

Pagely has a guide for the WordPress community on SSL, which is becoming rather more important now that Google’s seriously gunning for plain old http. Tim Nash has an even more in-depth guide to SSL that’s suitable regardless of whether or not you use WordPress, and has become my favorite to pass around.

There’s a cool little plugin that clones sites within a WordPress multisite network.

Carrie Dils with a pretty neat guide to using staging sites on WP Engine, which I’ve used for the last two years and still managed to learn from this guide. Maybe it helps when someone else writes it down. 🙂

You can, and therefore should, control the activation of your WooCommerce extensions so that you don’t confuse users of your plugin.

Web Development

Some pretty epic criticism of that “best-developers-are-always-hacking” tweet:

Joe, people are angry at this tweet. Can you guess why? Perhaps it’s the implication by you, as a CEO, that anyone not working over the holidays is not good enough?

A really enjoyable read about building a really fast website from the developer’s perspective. Lots of ego in here, but also lots of humor.

Improving site performance while using gifs gives a brief history of the file format, as well as the promised site performance tweeks.

Creating shapes with CSS, and then going further to create more advanced shapes.

Upload files to your raspberry pi from anywhere using a browser.

An introduction to local and session storage in JavaScript.

Web Accessibility

Dennis Lembree has a few things to say about parallax design, the issues it can cause for a slightly-larger-than-WordPress-sized market share of people, ending with a reading list of further resources on just about everything he covers in the short article that I would encourage everyone to read, especially designers.

Cristopher Broyles offers some insight on how data analytics can be used by businesses to improve their digital accessibility.

Some well-deserved praise for the W3C for leading the charge toward a fully inclusive web from the American Foundation for the Blind.

A tutorial on building accessible modal dialogs by Paul J. Adam on the Deque Systems blog. Definitely keep this in your toolbox.

Mailchimp has some quick tips for creating accessible email newsletters, and I for one hope that this means they’ll start working on the user interface they provide to create those newsletters so that it’s accessible too.

WooCommerce has a post about the importance of accessibility for online stores, which includes some tips and links to free tools you can use to get started with making your store more accessible, thus potentially gaining more customers.

Some very useful information on accessible emoji by Léonie Watson with a solution for displaying the contents of the aria-label attribute to users with vision by Adrian Roselli, who wanted to make sure the playing field was level and included people who don’t always understand what the emojis mean.

I’ve covered a lot in this week’s round-up, but if you think there’s something not included that should be, feel free to leave it in the comments below.

WordPress And Inclusive Design

4 December 2016 by Amanda Rush Leave a Comment

One of the most enjoyable parts of this year’s State of the Word address at WordCamp U.S. this weekend, for me at least, was the attention shown to inclusive design. That part hasn’t gotten a lot of coverage, but I think it’s important to highlight it. First, I’ll share Matt’s words on the subject, (thanks a metric ton, captioners, you guys are seriously awesome), and then, I’ll share a few thoughts. First, the quote. I’ve added links to the posts Matt references.

One of the other fun projects that I started this year is actually a blog called Design.blog. Who’s been to this so far or checked it out? I highly recommend you check it out. There’s been over 40 different folks who have contributed different essays writing about design and inclusion sometimes with or without tech. This is, I think, one of the areas. You might have noticed that this year’s programming at WordCamp US had some more of the human side, in addition to just the technical as before. I think a lot of our opportunities to grow over the coming year are on the human side and understanding the humanity of an open source project, and working together, and creating the code that’s going to touch humanity, as well. I’m going to call out two particular essays that I think you y’all should check out. First is from Kat Holmes. Inclusive design is for those who want to make the great products for greatest number of people. Inclusive design puts people in the center at the very start of the process. Exclusion happens when we solve problems using our own biases. Per story is amazing. She works at Microsoft. I believe she’s the head of Inclusive Design there. And actually wrote a story about playgrounds and playground designer and she talked about the how playground designers they started recognizing exclusion in the process and there’s so much that we have to learn there, and so please read this essay, check it out. The other one that I want to highlight is from Hajj Flemings, and I believe Hajj is in the audience here. Did I pronounce that right? Close enough, object. Some quotes from there Detroit’s future requires connecting the worlds of design, technology, and innovation is to neighborhoods. 53% of call businesses in Detroit operate without a website. 81% of people research a business online before making a purchase. Actually John had an amazing story that made me sort of wake up to some of my own learns about in this area, which is when you talked about that — there’s a lot of these businesses that aren’t even on Google Maps and I realized that in my life, I don’t realize that I’ve ever tried to go somewhere that wasn’t on Google Maps, Apple Maps? Absolutely. But I feel like Google Maps has everything. There’s entire swaths and communities and businesses that are not there. So WordPress, bringing the tools to bring them online is literally like the Christmas trees lighting up. Making them discoverable, and hopefully leading to them flourishing those businesses in the future. Correct me if I’m wrong, but they’re about hundred small business websites. Hundred websites for businesses that don’t have them yet.
>> Yeah, that’s the start and then we’re turning 100%…

MATT: I’m going to repeat that, that’s the start, and then we’re turning the hundred 100% of that, that’s amazing. Can we give him a round of applause? The urban revival in Detroit is very, very interesting. It’s 84% African-American and as a community, represents some of the biggest opportunities and some of the biggest challenges that we have across cities all over the world, actually. Some of those ways of being more accessible, and every WordPress release has become much more accessible, thanks to the hard work of the accessibility team that I highlighted last year and just want to give a continuing kudos to this year because they’ve been looking at the WCAG standards for every single release and the link there for when you look at the slides later basically shows the accessibility coding standards so if you’re a plugin developer or any sort of developer, you can learn this and check it out, and see how you can make your code available to more people. It’s interesting when you think about it that an interface, or an application that works well for someone with one arm also works well for a mother holding a baby. It works well for someone checking Twitter with one hand while typing with the other. As you make things more accessible, you’re addressing wider and wider audiences and bringing in more and more people, far beyond what you might have imagined when targeting a particular improvement, or thinking about it from an accessibility point of view.

I’m very happy to see inclusive design, (and by extension accessibility), get such a huge chunk of the State of the Word. I think this is more than any previous year, and I see this as a win for the WordPress Accessibility Team, WordPress itself, and of course for Morten Rand-Hendricksen, who has publicly advocated for a concerted effort by the WordPress community as a whole to work on accessibility for at least the past four years.

Speaking for myself, I think that WordPress is better for going in the direction of inclusive (or universal) design, instead of just accessibility. It’s not that I don’t think accessibility is important. It is. And as a person with disabilities, accessibility isn’t just an academic matter, it’s personal. But inclusion as a whole, that thing where everybody “gets to dance”, as it were, is also very important to me, and I think that if we focus on inclusion rather than just accessibility, we have an opportunity to get more done.

So yeah, it’s not accessibility is the WordPress way, it’s inclusion is the WordPress way. This isn’t mission accomplished for accessibility. There’s still a lot more work to do on that front. But I’m pleasantly surprised at how much effort the WordPress community as a whole, and Matt in particular, is putting into making sure that accessibility is a huge part of inclusion. It’s not big things you can turn into publicity wins. It’s the little things. For instance, in previous years, the graphics used during the State of the Word weren’t described. This year, they were, all throughout the presentation. That’s a win for accessibility as well as inclusion. I’m still waiting on Matt’s first photo with alternative text attached, but withJohn Maeda cracking the whip, I don’t think that’s going to be very far off.

A Comprehensive Guide To Manual WordPress Backups With A Screen Reader

25 November 2016 by Amanda Rush 2 Comments

Keeping regular backups of any website is critically important, and WordPress backups are no different. In this tutorial, I’ll show you how to back up WordPress properly so that your content, files, and WordPress settings remain intact should you ever have to restore your website. This tutorial assumes that you are using a shared host, and that you do not have easy access to command line tools.

Why Are WordPress Backups So Important?

You’ve probably heard more than once in your life that backing up your hard drive is very important. Hard drive backups are important because if backups don’t exist, and something happens to your hard drive or the computer it runs in, all your documents, photos, music, books, and any other data you have stored is gone, with no easy way to get it back. Your hard drive doesn’t care how sensitive your data is, or how sentimental you are about those photos, or that music, or those books. If your hardware fails, or you get a virus, or even if you just accidentally delete something, there’s no easy way to get it back without a backup.

The same holds true for WordPress backups. Web servers are, (or in the case of virtual private ones, run on), computers, and the computers that store and allow other people to access your website are just as vulnerable to hardware and other failures as the computer sitting on your desk or packed in your bag.

WordPress backups are specifically important because it’s the first step recommended during the WordPress update process. WordPress backups are a fail-safe in case an update doesn’t install properly, or if you’ve edited your theme and mistyped something and broken your site. They’re also important when you’re switching hosts. In order to move your site, you need to have a copy of it before you shut down your old hosting account and move to the new one.

Help Keep This Series Free

$825 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
well.

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.

$ Donation Amount:

Choose Your Donation Amount:

Personal Info

First Name *

Last Name

Email Address *

Donation Total: $5.00

WordPress backups happen in two stages

There are two stages to WordPress backups:

backing up the files
Backing up the database

The files

WordPress is built with PHP, JavaScript, CSS, and HTML code. This code lives in files, which then live in directories on your host’s server. Your plugins and themes are also PHP, JavaScript, CSS and HTML files, and they add to the files that already come with WordPress.

The database

The database is where WordPress stores all your settings and content. This includes the settings and options for your themes and plugins. It also stores the user accounts you use to log into and add content to your WordPress site.

If either the files or the database are left out of your backup, you don’t have a working version of WordPress, and will have to rebuild your site. Granted, replacing the files is easier than replacing the content and settings in the database, but you’ll still have to rebuild. For smaller sites, this can be accomplished relatively quickly. But for bigger sites, including sites that have a lot of content, this can become very painful very quickly. So it’s extremely important that you make sure both parts of your WordPress installation are backed up regularly.

Backing up the files

Although WordPress backups don’t have to be performed in any particular order, I usually start with backing up the files first. This is because it’s one of the easiest tasks, and, if there are a lot of files, (you’ve got a lot in your uploads directory, for instance), this part of the backup process can run in the background while you move on to the next step.

To back up your WordPress files, you’ll need an FTP client. Any accessible client will do the trick. I prefer WinSCP, but there are others, and you can use whichever one you prefer.

Configuring your FTP client

Once you have an FTP client installed, you’ll need to add a new entry so that you can access the files stored by your host. The specific information you’ll need will vary from host to host, so make sure you have this handy. However, the types of information you’ll need are the same across all setups. The pieces of information you need to have in order to connect to your host are:

Hostname: The address you’ll be connecting to.
Username: The name you’ll use to log in.
Password: The FTP password your host supplied you with, or that you set up yourself. This is not necessarily the same as your login credentials for your hosting account, although sometimes it will be. Consult your web host’s documentation for details.
Port number: Usually, this is port 21, which is the standard FTP port. Some web hosts on the smaller end do not provide secure FTP, and so this is the port you’ll likely use. If you’re connecting via secure FTP, you’ll most likely use port 22, although I have seen some hosting situations where a different port, (like 2222, for example), is used.
Protocol: Some clients, (like WinSCP), will ask you to choose a protocol during the account-adding process. You’ll need to check with your host to find out which protocols they support. If you can, choose either SFTP or SCP. FTP will do, but the two former protocols allow you to transfer data securely, while FTP does not.

Once I’m connected, which files do I need to back up?

You can always download a copy of WordPress’s core files directly from WordPress.org’s download page, and since this is the case, you don’t need to worry about making a copy of those files. You do, however, need to back up your wp-content directory, your wp-config.php file, and your .htaccess file.

wp-content

The wp-content directory is where all the content you’ve generated that isn’t stored in the database lives. This includes the themes and plugins you have installed, regardless of whether or not they are activated, and your media uploads. Depending on how much is in this directory, it can get quite large. It’s typically not themes and plugins that increase the size. What usually bulks up your wp-content directory is media, including audio, video, images, and any of the other file types WordPress supports.

wp-config.php

Your wp-config.php file contains your site-specific configuration. It tells WordPress everything it needs to know about your database, and contains any configuration customizations you’ve made. If you haven’t made any customizations, and you’d like to find out how far you can take wp-config.php, click here for a complete list of all the values you can edit. But before you make any changes, make sure you back this file up, because if you miss-type something, things will go wrong and you’ll either have to manually fix the errors, or revert back to your original version.

.htaccess

.htaccess, (pronounced “HT Access”), is a configuration file used by your host’s web server software. It is directory-specific, and it is used to alter configurations such as basic redirects, (such as redirecting requests for files that don’t exist to a “file not found” page), basic content password protection, and image or other media hotlinking prevention. The most common use of the .htaccess file in WordPress is to handle permalink settings. If your .htaccess file is lost or compromised, you can copy the basic .htaccess file for WordPress from the Codex. However, since this is a base copy, it will not take into account any customizations you’ve made, so you also need to ensure that you regularly back up any .htaccess files that are part of your WordPress installation. This can be done while you’re backing up your wp-content directory, via FTP/SFTP.

The Database

If you’re running your WordPress site on a shared host, creating a backup of your database can be a minefield when you’re also using a screen reader. This is because there are two types of intervening software you need to work with.

First, there’s your host’s control panel. Most hosts use cPanel, and while it’s not the most accessible experience, it’s useable, depending on the version. The version, however, can change between hosts, and there are at least five dozen of them. To add to the variation between versions, as far as I am aware, no one is working on the accessibility of cPanel, so the common apprehension experienced by every person with disabilities for whom accessibility is not optional upon hearing the word “update” is very real.

The second type of software that you have to interact with is one of two possible graphical user interfaces for managing your databases, cPanel’s built-in backup feature, or phpMyAdmin, a PHP script for interacting with MySQL databases. Like cPanel, there are multiple versions of phpMyAdmin, and the useability for screen readers varies between versions. As with cPanel, I am not aware of any accessibility work being done on phpMyAdmin.

First, I’ll cover cPanel’s built-in backup feature, specifically for cPanel version 56.0.38, although this is not the latest version. The latest version is 60, and so your milage may vary. and then, I’ll cover phpMyAdmin.

WordPress Backups With CPanel

CPanel provides a graphical user interface for managing just about every aspect of your hosting, including your databases. You can use it’s backup feature to create a downloadable copy of your WordPress database. You can also use it to generate a full backup of your entire site, but these backups are strictly for archival purposes. Relying on cPanel’s backup feature as part of your maintenance strategy is not recommended. It doesn’t provide any kind of scheduling, and you will need to create two partial backups, (one for your files and one for your database), in order to be able to restore from those backups should the need arrise. However, until you impliment a backup strategy, it’s better than not backing anything up at all.

To create a backup of your database, first log into cPanel. Next, look for “Backup Wizard” in the “files” section. You can do this by either arrowing through the page, or by using your screen reader’s find command. There are no headings on the page, so it’s arrow keys all the way down, coupled with heavy use of the find command. Once you’ve located “Backup Wizard”, press enter on that. On the next screen, you can navigate by headings. The only heading on the page is “Backup Wizard”, and you can skip past all the other links on the page by pressing “H”.

The next section on the page gives you a quick overview of the steps for creating a cPanel backup. It also lets you know what’s included in a full backup, delivered in a zip file for your convenience. Skim through this section, and press enter on the “backup” link. On the next screen, press “H” until you hear “Select partial backup”. Then, press enter on the “MySQL Databases” link. On the “MySQL Databases” screen, press “H” until you hear “Download a MySQL Database Backup”. Under this level-four heading, you’ll find a table that lists all of the databases that have been created, either by you or by install scripts. Find your WordPress database name, and press enter on that link. When you press enter on the linked database name, you’ll be presented with a standard file download prompt. Save the database file to your computer, but do not uncompress it. You’ll need to use the compressed copy if you ever need to restore the database.

If you’d like to avoid FTP or SFTp, or if for some reason you’re unable to log into your host using FTP, you can also use these steps to backup the files that make up your WordPress installation. Instead of choosing the database partial backup option, choose the files partial backup option, and continue as you would with the instructions for backing up your database. This feature creates a full backup of all your website files, not just the WordPress files. You don’t have the option of selecting the files that get backed up. Once again, this is better than no backup at all, but creating a full backup every time you create a backup isn’t necessarily the best long-term solution.

PHPMyAdmin

PhpMyAdmin is a free software tool written in PHP intended to handle the administration of MySQL and MariaDB databases on the web. As with cPanel, there are accessibility concerns, and the version of phpMyAdmin your host is running will impact how you interact with it. The version number is especially important if you’re a screen reader user. This is because, up until the 4.0 branch, phpMyAdmin wasn’t an accessible experience, but it was useable as long as you were willing to forego all the screen reader specific features like link lists, form fields lists, and headings lists, because all of them would actually decrease your productivity. It’s faster just to arrow through the screen. As of the 4.0 branch, the experience has gotten worse. I’ll be covering phpMyAdmin versions 3.8.5.1 and 4.7.5 in this tutorial. You can find the version your host is running by logging into phpMyAdmin, and using your screen reader’s find command to search for “Version information:”. Even though the 3.0 branch of phpMyAdmin is useable, you do not have the luxury of navigating by headings on most screens, and you do not have the luxury of a skiplink. There are a few dropdowns in the form of comboboxes, and some unlabeled form fields, but for the purposes of exporting your database as well as importing it should you need to restore from a backup, those dropdowns and form fields are not what you’ll be working with. You’ll be dealing with a couple of frames, lots of linked graphics, and you’ll need to pay careful attention to where you are within phpMyAdmin’s interface, since you won’t receive any feedback from your screen reader when you’ve activated a link unless you’ve specifically set it to automatically read the page content upon page load. So, with anger management powers activated, let’s get started.

To access phpMyAdmin, log into your host’s control panel, and navigate to the databases section. You can do this by either arrowing down the page, or using your screen reader’s find command to search for “DATABASES”. Directly below this text, you will find two links to phpMyAdmin. Press enter on one of them. phpMyAdmin will open a new browser window. If you attempt to force it to open in a new tab instead of a new window, you will be asked to log into it directly, so unless you have specific login credentials for that application, it’s best to just allow it to open in a new window. To ensure this happens, if you’re blocking popups in the browser, temporarily turn this off, and, once you’re done with phpMyAdmin, turn it back on again.

For phpMyAdmin 3.8.5.1, once you’re inside the phpMyAdmin interface, you’ll encounter two frames, neither of which have titles. The first frame contains navigation links specific to phpMyAdmin, as well as links for accessing your databases. The second frame is where all the operations happen.

In the first frame, find the link labeled with the name of your WordPress database. The list of database links will appear in an unordered list beneath the dropdown for selecting from recent database tables. Once you’ve found the link labeled with the name of your WordPress database, press enter on that.

Next, arrow down until you find a link labeled “export” in the second frame, and press enter on that. Once you’re on the next screen within the second frame, use your screen reader’s heading navigation keystroke to navigate to the heading labeled “Exporting tables from “db_name” database” where db_name will be replaced with the name of your WordPress database. On this screen, you can choose to perform a quick export, or a custom export. For the purposes of a full database backup, a quick export will be fine, and this is the default option.

After choosing the type of export you want to create, the next step is to choose the file format. PhpMyAdmin allows you to export all or part of a database in several formats, one of which, for some unexplained reason, is Microsoft Word 2000 (doc). The default is .sql, and i would recommend sticking with this unless you have a specific reason to change the format.

Once you choose the file format, press the “go” button. This is a true button, and will behave accordingly. When the “go” button is pressed, you’ll be presented with the standard “file download” dialog, and you can save the file to your PC.

Using phpMyAdmin 4.7.5, instead of content being separated into frames, you’ll find a series of lists on the page. Once you’ve launched the phpMyAdmin instance, navigate to the second list on the page, and find the link labeled with the name of your WordPress database. Once you’ve located the link, press enter. You’ll receive no feedback from your screen reader letting you know you’re on the next screen, so you’ll have to trust that you are. Next, either navigate to the fourth list on the page and then arrow down until you hear “Graphic Export Export” and then press enter, or use your screen reader or browser’s find command to search for “export” on the page, and then press enter on the linked graphic. You’ll once again receive no audible feedback that you’ve navigated to the desired screen, but you most likely have. Once you’re on the “export” screen, use your screen reader’s heading command to navigate to the first heading on the page. It’s a heading at level two. Alternatively, you can navigate to the first radio button on the page, labeled “Quick – display only the minimal options” and ensure that this is checked. Below the set of radio buttons, you’ll find a heading at level three designating the “format” section. Choose your preferred format from the dropdown and then press the “go” button. As with phpMyAdmin 3.5.8.1, this is a true button, and will act accordingly. You’ll be presented with the standard file download dialog, and you can proceed as you normally would from here.

Performing a manual WordPress backup while using a screen reader wil initially be a huge headache. However, it’s a fundamental skill worth having. I’ll cover some partially and fully automated methods for creating wordPress backups in upcoming posts, but knowing how to perform a manual backup is crucial should any of the automated methods be unavailable or should problems arise while using them. The process of performing a manual backup is daunting at first, but like any other technical skill, it gets easier with time and practice. If you’re tempted to skip learning this skill in order to avoid the headache and frustration, don’t yield to that temptation. Backups are fundamental to any security strategy. The best security tactics in the world will not help you if you’re not performing regular backups. Don’t throw away the investment you’ve made in your website by neglecting them. Doing so will result in a lot more headaches and frustration down the line.