The fireworks have already started here in Augusta, and I’ve been mulling over writing this for the last month, so it’s time to review 2015.

This year did not go anything like I planned in last year’s review, but I don’t see that as a bad thing.

There were several big goals I didn’t achieve, and will be transferring to 2016, but there were also a lot of things that happened unexpectedly which turned out to be great.

First, for the goals achieved.

I achieved my goal of co-hosting Office Hours, formerly Genesis Office Hours. This goes towards my goal of self-promotion generally and the goal of co-hosting that podcast in particular. I didn’t co-host the DradCast this year, but I’m transferring that one to this coming year. Goals achieved late are better than goals never achieved.

Slack accessibility hasn’t worked out so well, although there is a working solution for visually impaired people who want to contribute to WordPress and are using Instant Bird on Windows.

I haven’t contributed code to WordPress core yet, but still plan to do so, definitely in 2016. I did, however, contribute a little code to Utility Pro, the first premium accessible child theme for Genesis.

Now for the unexpected, as that’s what’s taken up most of this year.

In no particular order, I wrote a post for HeroPress, learned on a very personal level how generous the wordPress community can be, (for which I’m still deeply grateful and thankful), and I also learned, (thanks to the WPMorningCrew), that business and friends don’t necessarily have to be strictly separate. In other words, you can be friends with your colleagues, have fun with them, and still work with them. Those are lessons I’ll always take with me no matter where I end up.

I began working on a portfolio and listing projects, as well as collecting testimonials, and once I started on both those tasks, I found them easier to keep up with.

So what’s ahead for 2016? Firstly, over the last year, and with lots of thanks to the WordPress community, I’ve become a more confident person, which means I’m more comfortable sharing, whether that’s newly completed projects or code snippets or tutorials. I plan to continue working towards the goal of contributing code to wordPress itself, working on plugins and hopefully releasing some to the community for free, and of course, learning JavaScript deeply.

I’ve already been invited to speak at several WordPress events, so am planning to leave the shadows as it were and actually give talks instead of just being mentioned in other people’s talks. And of course writing more, both on and offline. I’d like to write some in-depth tutorials for this site, am participating in CopyBlogger’s cornerstone content challenge, and plan to be better at journaling, even if all of this comes down to writing ten minutes a day.

In regard to “passive” income sources like affiliate marketing, I plan to refocus on that. It’s tied to writing more content, and I didn’t give that as much attention as I wanted to this year, so I plan to do more towards incorporating affiliate marketing into my content this year.

I’ve picked up myself a copy of “Book Yourself Solid,” and one of my daily tasks will be working through the book and its associated workbook. I’m confident that putting in some work in the area of my business in general can only do good.

Finally, I plan to work on being less of a perfectionist, and being a lot less critical of myself. That doesn’t mean I’m settling for mediocre work, but it does mean that I don’t want to spend so much energy beating myself up whenever things go wrong. Failure when it occurs can be a learning opportunity along with successes.

So here’s to 2016, and I hope we all have a successful and prosperous one.

A few weeks ago, I put out an initial call for volunteers for 4.5. In the spirit of the much-commented @wonderboymusic 4.4 Wishlist post, I’d like to extend the call a bit more.

Source: WordPress › WordPress 4.5: What’s on your Wishlist? – Make WordPress Core

The first core chat for the WordPress 4.5 development cycle will be next Wednesday at 4PM Eastern. If there are things you’d like to see considered for 4.5, click the link above, log in with your username and password, and leave a comment. Everyone has a voice, and all of this is completely transparent, so if there’s something you’d like considered, speak up now.

10up, one of the bigger WordPress agencies, has released Flexbox support for IE8 and 9 that also happens to be GPL.

The support is included in flexbox.js, and can be used in any project regardless of whether or not it is built on top of WordPress. There’s a complete guide to Flexbox via CSS Tricks, and you can find the JavaScript on 10up’s GitHub.

If you’re forced to support older browsers, this script will allow you to create the same kind of layout you have for the newer, shinier ones.

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.

sensorshipis bad

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. 🙂

WordPress Support Team Wapuu

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.

I was browsing through Twitter, and came upon an article I thought might be interesting and thought-provoking reading. Ironically, it’s an article about the moral failure of the computer science community. So I open the page, and I’m reminded of why I have no sympathy for, nor can I empathize much with, online advertisers.

It comes down to the fact that almost all of you aggressively scrolljack.

This goes for ads, as well as those trendy newsletter sign-ups that steal cursor focus away from the content you’re promoting and drop it in your sign-up form or advertisement, like I’m suddenly going to want to stop what I’m doing and do what you want me to do: Buy whatever you’re advertising or sign up for your newsletter.

In order to get back to what I was doing in the first place, (reading your content), I have to resort to the following process.

  1. Open the page, press “H” to jump to the headline. Maybe read a couple of lines.
  2. Page refreshes, or some other scrolljacking event happens. Get dropped back to the top of the page.
  3. Press ctrl+f to bring up the find dialog.
  4. Think of a word or phrase which hasn’t occurred multiple times within the content, in order to hit my target on the first shot, and beat the next page refresh or scrolljack.
  5. Read the next couple lines.
  6. Repeat steps 1 through 5 until I either get to the end of the content, or, depending on how long the content is, quit at some point because I’m tired of repeating myself and I’m frustrated and don’t want to fight with the keyboard, the screen reader, and the browser any longer.

It’s stuff like this that makes people install adblockers. Or turn off JavaScript. Or just not visit your sites and read your content at all, and hence, not buy what you’re selling.

I might be able to empathize with online advertisers if I weren’t trading my own sanity in the process.

The worst part of all this is that it has nothing to do with accessibility, but extremely basic user experience. I’d really like to think it comes down to lack of awareness, but I’d have to engage in a hell of a lot of mental gymnastics to do that. So I have no choice but to chalk it up to a lack of concern for users.

And if I can plainly see that you don’t care about the experience of your users when it comes to something as simple as reading your content, what makes you think I’m going to believe you’ll care more after I’ve purchased your product or signed up for your newsletter?