Amanda Rush

Layout tables are probably one of the most hated web things within the accessibility community. They used to be all the rage before CSS became popular, and they were used inline among other HTML elements to control positioning.

As a result of their overuse, screen readers ignore them by default. Well, they mostly do.

VoiceOver, the built-in screen reader on the Mack, is apparently the exception. As long as a layout table has no borders, VoiceOver will ignore it as such and only give you the option to view data tables from its rotor. But if you add any kind of border, including transparent ones, that goes out the window and VoiceOver will report the existence of the table from the rotor. This is true regardless of whether or not the layout table has headers.

Layout tables are bad. Layout tables without headers are even worse. Layout tables with borders can have the added value of extra annoyance for VoiceOver users.

Friends don’t let friends use layout tables, so as a service to the WordPress community, here’s yet one more reason not to use them. See the link above for all kinds of CodePen goodness and screenshots.

I’ve been asked again and again over the years what the absolute basics of web accessibility are. And while I always thought that it is not so difficult to find resources about these basics, the recurrence of that question prompted me to finally write my own take on this topic.

Source: The web accessibility basics – Marco’s Accessibility Blog

This guide to accessibility basics is a very handy reference for anyone who’s interested in getting started with accessibility. Reading WCAG can seem daunting, (I don’t know of a single accessibility professional who truly enjoys the experience), and if you’re only reading WCAG and its associated documents, accessibility will appear to be harder than it actually is.

The takeaway from this guide is: Use native HTML elements where possible. Where it’s not possible, use Aria to compliment your custom elements and make sure to provide the semantic information that’s no longer implicitly provided, which is basically everything: Role, state, and property.

There are talks on WordPress.TV about all of this, but this guide along with several of the other posts at Marco’s blog can serve as a handy textual reference.

Why yes, you can haz accessible lightboxes. And with just a bit of work, this could also be used in WordPress things. It’s GPL, so go have fun.

Two years later.

Source: The HTTP 451 Error Code for Censorship Is Now an Internet Standard

The idealist in me wants to think this will do some good for users. Sensorship is not a good thing, for too many reasons to mention, and since net neutrality is on the chopping block and it’ll only be a matter of time before it’s completely gone, this seems as good a way as any to fight back.

As an aside, being in favor of net neutrality should not be a partisan issue. Users, including those who swallow whatever talking points they’re fed on the subject, especially by those who refer to themselves as conservatives but aren’t really. The only groups who will benefit from a lack of net neutrality are those who are interested in silencing voices. In other words, sensors. And sensors serve no one but themselves, or whoever’s paying their bills.

This post is in response to this one, and you should go read it first before reading the rest of this one.

We’ve probably all heard a phrase that goes something along these lines.

Keep your personal life and problems private and out of your business dealings.

That’s not an exact quote, but it’s definitely a skill that you learn as you go into business. Never show your weaknesses, because they erode client trust. If your clients see that you’re having problems, and that you’re public about them, they’re less likely to work with you. If your clients know that you have any kind of mental illness, or physical illness, they’re afraid it’s going to effect your work, and they’re less likely to hire you.

This is a mindset that has become ingrained within just about every type of business community, and until I became a part of the WordPress community, I thought it was just the rules of the road. Since I joined the WordPress community, I have come to view it as dangerous, destructive, and the ultimate killer of productivity.

I have come to believe that wellness, (shlemah, completeness or complete personal well-being), makes up at least half of what we would consider productivity, and is the first priority over everything else, including skillset or the amount of tasks you complete in a day for a project or projects.

This is hard to admit, because it means that I’ve had to unlearn a whole lot. I’m still not done unlearning, and I’m definitely not done implementing what I’ve relearned. I’m still working on that and trying to figure out the logistics.

But at this point, I believe that nothing is more important than wellness. Not personal glory, not deadlines, not accessibility, not good code, nothing.

It has become a key factor in picking clients or projects. Whether or not a client cares about their own wellness enough isn’t something I have control over. Whether or not I make room in my busy schedule for my own wellness is something I do have control over.

I’m not posting this to preach at anyone so much as for personal accountability. I’m going to need the help of the WordPress community to figure all this out beyond the first step. There will be financial implications to this. To be honest, there’s not enough money to go around in the first place, and I’m pretty certain this is going to effect at least one of my off and on client relationships negatively, and it’s the one that usually pays the most to boot.

Also, I’m going to have to start charging for every piece of accessibility advice I give. As much as I love helping the community achieve accessibility goodness, that comes at a cost to me, and if I help with your theme or plugin, even if you’re giving it away for free, I’ll still have to charge for that help. I’m pretty sure most of you can’t afford my ideal hourly rate of $200 per hour, so I’ll be testing out some lower rates to see what works, as well as testing out some sort of pay-by-the-minute setup. Clarity won’t work for this, as the interface is almost completely unusable for both myself and any other clients who are visually impaired and use a screen reader. So I’ll be building something with Gravity Forms and charging a minimum amount for a minimum amount of minutes.

I’d like to hope that no one in the WordPress community takes this personally. Because trust me, it’s not. And we’re going to need to work together to figure out a rate that this particular market will bear. Most of the money that’s made in the accessibility community is made from Fortune 50 or Fortune 500 companies, and the rates are determined accordingly. This community is obviously not the Fortune 50 or Fortune 500, and yet there needs to be a solution for the little guy or little business who cares deeply about doing the right thing and making their products and software accessible, and yet can’t afford Fortune 50 or Fortune 500 rates for practical advice.

So all of this, I hope, will be a journey we can go on together, hopefully creating something that works for the little guy, gets the right thing done, and makes the world a better place for millions of people.

Now to publish this and see what the fall-out is.

Here’s hoping it doesn’t go completely wrong. 🙂

There’s been some discussion of late around who the typical WordPress user is, and what they can and cannot learn. I’d like to take this discussion in a slightly different direction, because I think that asking what a WordPress user can and cannot learn is the wrong question. In my experience, it comes down to what WordPress users will and won’t learn.

Before I go any further down this path, I’ll point out that this has nothing to do with intelligence. It has to do with frustration on the part of users by a barrier of entry that is perceived to be high. In some cases, it actually is, but in others, it’s a high barrier due to a number of factors, some of which are completely outside WordPress’s control and other factors that are within the control of those who are building the tools meant for average users, both within the WordPress project itself and the surrounding community.

None of the data I have is based on research. It’s only anecdotal, based on my years of teaching blind people how to use their technology, and how to use WordPress in particular, through the Cisco Academy for the Vision Impaired WordPress and CMS Fundamentals course.

This course aims to teach users how to build a basic website with WordPress’s built-in features, along with some plugins recommended based on ease of use with screen readers, and accessibility-ready themes. During its first successful run, some code was covered, but I found that my students could not tolerate the extra work involved in using code to make what they perceived were simple customizations.

For me, the code bit was easy, and I figured that since it was literally “I’m going to give you some things to copy and paste, and tell you where to put them in your theme’s files,” I thought it would be easy for my students too.

It turns out I was wrong, because my students weren’t, and still aren’t, willing to tolerate the extra work involved, no matter how little it actually is.

Having a good understanding of what users will and won’t tolerate when it comes to WordPress and the websites they build with it is critical to the further success of WordPress down the line. If we tell users that WordPress is a piece of cake to use, then it has to be so. We can’t expect that users who are not developers are going to do things like use their browser’s development tools to troubleshoot an issue. By way of illustration, every single support call I take, (and yes, they’re calls, as in on Skype or on the phone, because the type of user I deal with on a regular basis considers user forums too high of a barrier to entry when it comes to getting support), involves me using my developer tools on their site to see if what they’re reporting to me is actually occurring, or to get a better handle on what’s actually going on before I start walking them through how to solve a particular problem.

WordPress can be powerful, or it can be easy. And I think it’s time we pick one of those options. making something powerful means that it has to become more complex. Once it starts becoming more complex, it’s no longer easy. I think that, at least for wordPress, we may need to abandon the “easy” rhetoric. It’s almost always never true, and if we tell users that something is easy to use, and they find out that in their experience it’s not, they become frustrated and move to another platform like Wix or SquareSpace.

And we shouldn’t be a Wix or Squarespace knock-off, we should be WordPress.