Picture frame

I’ve written before about how important it is to add images to your content, even if you’re totally blind. In that post, I recommended Flicker as a great source for free images, and also cautioned that attribution has to be given when someone’s image is used. Those tips still apply, but there’s an easier way to find those free images and make sure they have proper attribution.

The Flickr – Pick a Picture plugin will allow you to search for free images to use from within WordPress itself, so you can avoid the mess that is the Flickr website if you’re using assistive technology.

Once you’ve installed and activated the plugin, you’ll see a new settings screen under the “settings” section of your WordPress administration panel, and you’ll also see a “Flickr – pick a pic” bchoice in the toolbar above the content area of your WordPress post/page editor. When you want to add an image, select that and a new window will open. If you’re using a screen reader, the window will appear at the bottom of the page.

Search for the kind of picture you want, and the plugin will return search results with your search term either in the caption, description, or name of the image. The plugin will also make sure that only Creative Commons images are searched so you don’t accidentally use someone’s copyrighted work. Each image will have a “choose” button near it. For screen reader users, it will appear underneath the link labeled “graphic” with a whole bunch of numbers. If you’re sighted, and you want to see a larger version of the image, click on the thumbnail to see a larger version. If you’re blind, this isn’t going to matter.

Once you press “choose,” you’ll see some options to edit the filename, alternative text, (and we all know how important the alt attribute is), the caption and the description. The caption already contains the attribution for the image, and you can leave this be or add to it. Don’t remove it though. The description is there so that in regard to the WordPress media editor, you have descriptions you can see for each image that gets uploaded.

The plugin will upload the image you choose to your own media library, so you’re not stuck if the image gets deleted. Its screens are also much easier to deal with than the standard WordPress media editor.

Hopefully, by installing this plugin, you’ll find it easier to add images to your content. They’re a great way to enrich your site, and they can make or break the content you’ve put all that hard work into. So next time you’re writing, or next time you pan to write, install Flicker — Pick a Picture and add some free images.

WordPress post revisions can be useful when you’re writing content. It’s what allows WordPress to auto-save drafts while you’re in the post editor so you don’t lose your work should something go wrong, like when your browser crashes. Every time you press “save draft,” a new one is created.

But over time, WordPress post revisions can add some serious overhead to your database, which can

  • Make your site slow and unresponsive
  • Take up needed space in your database
  • Decrease your search engine rankings

.

Why does the time it takes my site to load matter?

The time it takes your site to load matters because visitors will decide to stick around for your awesome content based on how long it takes to get to their screens. Visitors like times around three seconds. So, for that matter, do search engines. So if your site loads slower than that, you’re losing readers.

[tweet “If your site takes longer than three seconds to load, you’re leaving money on the table.”]

While WordPress post revisions aren’t the only thing that can slow down your site, they are a contributing factor. they’re also one of the easiest aspects of site performance to manage.

Have questions about WordPress site performance? click here to get answers.

Why does the size of my database matter?

The size of your WordPress database matters because it effects your site’s performance, and it also effects the amount of work your web host’s server has to do to casche resources, no matter what casching method you use. Also, if you’re on a smaller hosting plan, you are often limited significantly by the database size your web host will allow. Finally, the size of your database can also effect how hard it is to move your site from one web host to another, and switching hosts is something that happens throughout the lifetime of every website. On most web hosts, especially if you’re using PHPMyAdmin instead of the command line, the database size is limited to 8MB. That means if your database is bigger than that, you’re not moving it over. PHPMyAdmin does offer the option of breaking up imports into smaller pieces, but even it doesn’t recommend this. And web hosts don’t often increase the size limit, even for a short time.

Once again, while WordPress post revisions aren’t the only thing that contributes to the size of your database, they are a factor.

[tweet “When it comes to your database, size really does matter.”]

As I said above, search engines and visitors like sites that load in three seconds or less. So if you make sure your site loads within that time, you’ll keep both your visitors and the search engines happy, which is a win-win. Site performance isn’t the only thing that makes people and search engines happy, but as with everything else I’ve mentioned so far, it’s a factor. You can write the best content in the world, but if site speed is slow, your efforts are wasted.

OK, you’ve convinced me. How do I manage my WordPress post revisions?

Now that we’ve gotten all of the “whys” out of the way, I’m going to show you what WordPress post revisions are, how you can prevent them from being saved if you want, and how to remove them so that your database contains less clutter.

How do WordPress post revisions work?

WordPress creates a post revision in one of two ways. It creates one when the post auto-saves, and this happens once for each post for each user. It also creates a post revision every time you press “save draft.” WordPress lets you compare post revisions so you can track changes to a post, which is great for editors, and you can restore a revision if you need to undo a change and you don’t want to spend time manually doing it. This is useful if you’re deleting paragraphs of text. By default, WordPress keeps all post revisions. You have to give it instructions by way of wp-config if you want to either turn the feature off completely, or limit post revisions.

If you’re using WordPress.com to host your site, they’re taking care of things for you, which includes keeping your database free from clutter. If you’re using managed WordPress hosting, post revisions are also managed for you. But if you’re self-hosting, either on your own VPS or on a shared hosting account, you’ll have to manage them on your own.

I want to limit the number of post revisions WordPress keeps. How do I do this?

You can limit the number of WordPress post revisions by adding the following snippet to your wp-config file.

define( 'WP_POST_REVISIONS', 3 );

The number after the comma in the above example tells WordPress how many post revisions to keep. You can set this to whatever you want, but remember to keep it at the low end.

What about disabling post revisions altogether?

You can also use something similar to the above example to disable WordPress post revisions completely. To do this, you’ll need to change the example in the following way.

define( 'WP_POST_REVISIONS', false );

Removing the number and replacing it with “false” will tell WordPress not to save post revisions. Once you’ve added one of these constants to your wp-config file, you can now deal with the WordPress post revisions that are already in your database.

How do I get rid of WordPress post revisions that are already saved?

Even though you’ve added one of the above constants to your wp-config file, your database still contains any post revisions that were created as you’ve added content. In WordPress, each revision is a copy of the entire post, with the content that’s there when the revision is saved. So the next step is to remove the ones that are already in your database. By doing this, you’ll make your database smaller and easier to optimize. You can remove WordPress post revisions by running an SQL query, but if you’re not comfortable doing that, a simpler way to do it is with a plugin.

The Optimize Database after Deleting Revisions plugin will allow you to remove the WordPress post revisions you don’t need, and it will also let you keep them for a specific post should you decide to do that. It also optimizes your database after the revisions have been deleted, thus saving space in your database.

If you’re using this plugin to get rid of all revisions, and you know you’re not going to keep any, be sure to deactivate and delete it once you’re done using it so you don’t have unnecessary code hanging around your WordPress installation.

Managing WordPress post revisions is an easy way to make sure your website does not become slow or unresponsive, and if you’re on a small hosting plan, it’s also a great way to make sure you don’t reach your database size limits before you planned to. It’s also an excellent way to keep both your visitors and the search engines happy. If you have questions about anything in this tutorial, click here to get one-on-one support and I’ll be happy to walk you through any part of it.

http://wordpress.tv/2014/11/14/cory-miller-how-simply-clicking-publish-changed-my-life/

This lightning talk was given at WordCamp San Francisco last year. I’m sharing it because I’m pretty sure I’m not the only one who’s a raging perfectionist, and I also know that I’ve had some ideas or even just things to say that I’ve left unexecuted or unsaid because I didn’t think they were good enough, and we all need a reminder not to let that happen. The takeaway from this talk is to not let the perfect be the enemy of the good. We all tend to be the most critical of ourselves, and if we let whatever we’re working on or want to work on not make it to the light of day because it’s not perfect, then we’re missing opportunities to help ourselves and more importantly, to help others.

Just pressing publish, (writing something and getting it out there, shipping a personal or client project, or just reaching out to someone we’ve never talked to before), doesn’t mean we won’t fail. But it also means if we don’t publish, we won’t succeed either. So don’t let “it’s not good enough” determine whether something you’ve created gets out there.

Mika Epstein has a post on why you shouldn’t use copy protection to try to protect your content. This of course applies to websites. I think you should go read the post, but the short version is this: It doesn’t work.

If you look at the post, you’ll see some very easy ways to get around said protection: Developer tools. These are the tools developers will need to bring up if we’re going to help you fix problems with your site, especially when we’re answering questions in the WordPress support forums. By disabling right-clicking, (which is what copy protection relies on), it’s harder for us to open those tools. But it’s not impossible.

One of the other methods used in copy protection is disabling copy/paste capabilities. This breaks things for adaptive technology users in all kinds of ways, basically resulting in “We can’t read your content.” If we can’t read your content, we’re not going to visit your site. And we’re going to tell our friends about it. Who will also avoid your site, tell their friends, you get the picture.

Stealing content is not cool. We all pretty much agree on that, content thieves obviously excluded. But given that the standard methods of copy protection don’t work in the first place, people who create websites have a really good reason not to use it.

Nothing can replace the eyes of a skilled professional when it comes to web accessibility testing. This is because so much of determining a website’s accessibility is subjective enough that an automated tool cannot help you when it comes to making definitive judgments about whether disabled people who visit your site and interact with it can actually use it.

But before I tell you why automated web accessibility testing is bad in more detail, I want to tell you what it’s good at, because despite not being a complete solution, there are some aspects of accessibility testing they excel at.

Piles of Code

A good web accessibility audit involves an in-depth, manual look at all the generated source code that makes up a website. Doing this is the best way to find out if problems exist, where they are, why they’re occurring, and how to fix them once they’re found. Doing everything manually is great if the website I’m working on is small. But once websites started becoming larger, web accessibility professionals needed a way to quickly scan through thousands of lines of generated source code to get a basic idea of where things stood.

This is where automated tools come in. They help by providing a general layout of the accessibility landscape, and they provide a list of things which need further attention in a manual audit. When you’re staring at a page that contains hundreds or thousands of lines of JavaScript, HTML and CSS, (like, for example, the Yahoo homepage or the Facebook homepage), automated tools can be a great help. On large sites, there really is no other way to find all the errors than automating the task. This includes sites that are using a templating system, such as WordPress sites. When conquering these, you’ll need to use an automated tool that crawls the entire site to get the assessment done. When I began working on Utility Pro, running it through an automated tool was the first thing I did in order to find out what I needed to start work on first, and in what priority.

Some errors don’t need human inspection

One of the best examples of errors that an automated tool can save time on is images without alternative text. In cases where there is no alternative text, an automated tool is used to document every occurrence, instead of an auditor manually going through and finding each one. But in cases where images have alternative text, and it’s not meaningful, a manual audit will find these and suggest meaningful text.

An automated tool lays the groundwork for a manual audit

The most appropriate way to use an automated web accessibility tool is not to generate a comprehensive list of pass or fail judgments on the site being tested, but to give an auditor a list of things that need a closer look. A good tool will provide a list of errors with line numbers and snippets of code that’s causing them. This information helps an auditor decide whether the problem really is a problem, so they can then tell the client why it’s a problem and suggest ways to fix it. More importantly, it’s a good way to find patterns of errors, which then helps an auditor determine the best way to help the client integrate accessibility best practices into their workflow.

Automated web accessibility tools can also help find exceptions in an otherwise accessible site. I’ve created sites or added content which contained good markup, but since underlying tools may change what happens to that markup, I’ll run the site through an automated tool and sometimes find errors I hadn’t realized were introduced. So in short, automated tools are great for sanity checks, and make sure that a manual audit doesn’t miss the obvious.

And now, the bad

Most of the bad things that get mentioned about automated web accessibility testing are related to the subjective nature of accessibility. There are also numerous ways to make a site more useable for people with disabilities that an automated tool will never alert you to. Automated tools can offer false positive and false negative results, and they have a lot of trouble with dynamic features, which have become more and more prevalent on the web and are not going away any time soon.

Now for some statistics

While working with WordPress and the Genesis framework, I’ve found that automated tools give me about twenty percent accurate results when it comes to web accessibility best practices. Thirty percent of what the tool finds I can use as guideance for further manual review. That leaves fifty percent that is straight up manual review. That fifty percent includes everything related to forms, and, since automated tools can only test HTML and CSS, also includes JavaScript, AJAX, and any other client-side scripting.

Does this mean you shouldn’t use automated tools?

I don’t mean to suggest by any of the above that you should never use an automated tool. But the thing to keep in mind is that an automated tool is just that, a tool. It can help with productivity, and helps with the accuracy of the final report. They also help with getting started with the basics of accessibility and can help developers and designers begin learning about it. But when using automated tools, in order to get the most milage, you’ll need to be well-trained in accessibility, understand how to read their results, and remember that what that tools tells you is not the final say in determining whether your site is accessible.

One thing that often comes up when performing an accessibility audit of a website, is the lack of the alt attribute when it comes to images. Fortunately, this is something that can be easily fixed, and you can start adding it to your images right now and see an immediate improvement in the accessibility of your site. In this tutorial, I’m going to explain what the alt attribute is, how and why to use it, and how you can do so using WordPress.

What is the alt attribute?

The alt attribute is part of the HTML tag which is used to insert images into web pages. Alt is short for alternative, and it defines text that is displayed as an alternative in case an image doesn’t display correctly in a browser. It also gives search engines and screen readers an idea of what the image contains. For screen reader users, it means the difference between “graphic img1000000000” or something similar and “graphic man holding a football” or other similar descriptive text.

What kinds of images need alt attributes?

You may be thinking that if there’s an image, it needs an alt attribute. However, this is not always the case. For example, if an image is decorative, such as images used solely for creative effect, the alt attribute should be left blank, like this:

In the case of an image that’s used as a bullet, you can use this:
*

Two ways to add an alt attribute in WordPress

If you’re using WordPress, you have two options for adding the alt attribute to your non-decorative images. The first is to manually add it to the tag. If you’re using the text editor, and manually inserting your images, it looks like this:
brief description of your image
If you’re inserting media using WordPress’s built-in media library, this gets a little easier. When adding the details for your image, there is a field that allows you to enter an alt attribute. Adding some meangful text to this field will ensure that your alt attribute is added without much work.

What counts as meangful text and how long should the text be?

The final thing to keep in mind when you’re adding alt attributes to your images is to make sure the text is meangful. For instance, if you have an image of a woman standing at the check-in counter at an airport, instead of labeling that image “woman,” try labeling that image something like “woman standing at airport check-in counter.” Also, keep your descriptions brief. Don’t use any more than fifty characters. If you need to add a longer description, in WordPress you can add this longer description to the caption field. There’s also a caption attribute you can use if you’re adding it by hand.

The alt attribute is an easy way to increase the accessibility of your website and content, and it’s also an easy way to help the search engines and other people get a better idea of what you’re saying with your images. If you’re going to use images as part of your content, (and you should), make sure that everyone can enjoy them. After all, you’ve spent a lot of time either finding those images or creating them yourself. With an alt attribute for each one, you can ensure the widest possible reach for your work.