Featured

Accessible Zen Reaches 1.1

Version 1.1 of Accessible Zen hit the WordPress theme directory today. Download it now! :)

I added one new feature, improved one area and fixed a number of bugs for this release.

The New Feature

I’ve added contextual help to the Themes page in the WordPress Dashboard. It gives theme users a bit more information about the Accessible Zen inline with their experience.

The Big Addition

Accessible Zen now sports the accessibility-ready tag. Users can find themes that keep accessibility in mind from the start via that tag. They all follow specific accessibility guidelines for themes in the directory. Accessible Zen has always followed these guidelines since its launch, and now has added the tag since it went live on WordPress.org a few weeks ago.

Customizer Improvements

I’ve set better default options for the few of Accessible Zen’s Customizer theme options, which should make for a better experience upon theme activation. Note: This may cause users to have to set their options again via the Customizer.

You can read about all the updates below.

Changelog for 1.1

  • Add contextual help to theme.
  • Improve Customizer features and set better default options. This may cause users to have to set their options again via the Customizer.
  • Add appropriate theme tags for WordPress, version 3.8, including accessibility-ready.
  • Remove bottom border on hover on site title.
  • Add new screenshot according to WordPress, version 3.8 standards.
  • Update Genericons to version 3.0.2.
  • Move changelog to separate file.

Download Accessible Zen or write a theme review.

What Should Twenty Fifteen Look Like?

Watching the Twenties, the WordPress default themes, evolve over the last few WordPress releases has been a blast.

Konstantin Obenland wrote a post about what he’d like to see happen with the next default WordPress theme, Twenty Fifteen:

But most importantly: Let changes only be in style.css. That’s it! No additional functionality or bloat. If anything, we take unneeded code out. This doesn’t mean it can’t look good. It doesn’t mean it will be less awesome than its predecessors. CSS is a powerful tool, if in the right hands.

Aaron Jorbin followed up with his own ideas for Twenty Fifteen.

I would like to propose that Twenty Fifteen be a single page app largely done in JavaScript. This will require the addition of the Rest API the WP API team is building, but would enable us to demonstrate what is possible for a theme with almost no PHP. Imagine a theme where the only PHP is functions.php and index.php.

The two conversations I’ve enjoyed seeing spring up around these posts are enabling WordPress Core to support more complex theme features, as read in the comments on Konstantin’s post, and developing a content-focused JavaScript app responsibly, as read in the comments on Aaron’s post.

What would I like to see in Twenty Fifteen? The simplest architecture possible.

What’s that mean? I’d love to see a theme with as few files possible. Most people don’t know that WordPress only requires two theme files. Most theme developers would struggle to make this happen, especially if they’re building a full-featured theme. Also, this approach nets little for the end user. However, it would force everyone to make decisions: theme authors and theme users. What do you really need?

Imagine, a theme with less than 10 files. Critics of the WordPress theming process sometimes say its bloated or hard to grasp. What if we pare it down as much as possible?

Aside

The Changing Web

Fascinatingly, to me, anyway, while many of us prefer to concentrate on design, content, and experience, it continues to be necessary to remind our work comrades (or inform younguns) about web standards, accessibility, and progressive enhancement. When a site like Facebook stops functioning when a script forgets to load, that is a failure of education and understanding, and all of us have a stake in reaching out to our fellow developers to make sure that, in addition to the new fancy tricks they’ve mastered, they also learn the basics of web standards, without which our whole shared system implodes.

This doesn’t mean “go be an HTML guru.” It does mean cherish the lessons of the recent past, and share them with those who missed them (or missed the point). Wisdom is not a job, but it is always an asset.

Jeffrey Zeldman in It’s 2014. Is Web Design Dead?, a response to Jeff Croft’s Web Standards Killed the HTML Star

I love HTML and CSS. They’re as much art as they are science. That’s why I create with them.

If we view the average web worker’s skill stack as a cake (this kind of cake – opens in a new window), at least two of those layers are HTML and CSS. You can make that third layer and icing out of whatever you’d like: design, UX, accessibility, etc. And guess what, you can change that or add layers. It’s the web! Fluidity and flexibility mean something around here, but you’ll always need those two layers of HTML and CSS. They form your base and will serve you well. The rest is up to you. Do your best to welcome change, in technology and yourself.

Hello 2014

I realized a few days ago after listening to the Non-Breaking Space Show’s Year End Spectacular that I hadn’t posted about my new year’s goals in 2013. Lame. I did in 2011 and 2012.

A Review

So let’s fix that this year. First, a quick review of 2013.

On to the goals! I do best with goals when they’re few and focused. After all you can’t become proficient at something when you don’t work at it, and you can’t work at something if you lack the time.

Professional

  1. Keep contributing to the WordPress Accessibility team. I’m excited about all the progress we’re making.
  2. Release Accessible Alexandria and Accessible D.C. The world needs more accessible websites.
  3. Start writing a book on accessibility. I’ve always wanted to write a book.

Personal

I’m still working on these. More on those later. :D

Now, let’s get to goal smashing!

Issue No. 300

The Story of my First Open Source Contribution

Konstantin Obenland merged my first open source code contribution about a few months ago. And despite some hiccups thanks to an overlooked setting in Github on my part, I got full credit and I’m now on the contributors list for Underscores, a popular WordPress starter theme.Yay!

A screenshot of my first open source code contribution on Github, issue number 300 for the Underscores WordPress theme.

I’ve used WordPress for almost five years, so finally having a chance to write code that helps a WordPress project is exciting. I wanted to share the story of how I went from user to code contributor and what I’ve learned in the process.

I started out as just a WordPress user so I know the delta between user and code contributor well. But I believe anyone can learn to contribute code and reading stories like Andrew Nacin’s first commit to WordPress or Aaron Jorbin’s contribution inspired me to write this.

Start Somewhere

If you want to contribute code, it’s hard to know where to start. Where can you fit in? How do you know what needs to be done? You have to start somewhere. Find a project you’re passionate about and use it. For me, that meant Underscores. In my first web development job at The Arc, I started building WordPress themes. I began using the Toolbox theme, but it soon evolved into Underscores. I built a few themes with Underscores so I became familiar with its code and its goals. I also used it as a starting point for all my custom themes. I grew to love it for both its strengths and weaknesses. Without some of this knowledge, I couldn’t add my own expertise in the form of code.

Listen and Learn

I started following Underscores on Github, getting a load of email notifications when issues and commits happened. It was overwhelming but also educational. By reading through a number of the Github issues, I learned about how the maintainers of Underscores approached adding new features, fixing bugs and handling pull requests. When jumping into a new project, you can’t contribute without knowing how others have contributed. This proved most important for Underscores because it doesn’t have any official documentation for contributing or a roadmap.

Find a Focus, be Patient

Once I started to become familiar with all things Underscores, I started to think about how I could contribute code. I’m an accessibility advocate so that made the most sense, but I remember telling Aaron Jorbin at a WordPress DC meetup that I wasn’t sure what could be done from an accessibility standpoint. That’s made more difficult since Underscores serves the community as a starter theme and lacks a real, polished front end. Sometimes, finding your focus takes takes time. However, once I saw Trac ticket 24766 I thought taking a similar approach in Underscores would be welcome. So I started writing code to remove the title attributes in Underscores.

Commit

Ripping out all of the title attributes turned out to be a big task. I touched seven files in total, and broke the changes down into three commits. However, I planned for it to be only two commits originally. I ran into the dreaded merge conflict after the first round of changes because so much time passed between working on the changes. I persevered though and cleaned things up and committed my code. I had to wait awhile before finding out whether my change would be accepted. When I say commit, I’m talking less about committed code, and more about making a plan and carrying it out. Be thoughtful, methodical and patient.

Keep Going

Seeing my name on the contributor’s list on the Underscores website felt like nothing else. As a writer, I published thousands of stories in newspapers and magazines. In doing so, receiving feedback from readers was rare. However, when you’re contributing code to an open source project you see feedback on multiple fronts. Project maintainers and fellow developers comment on your code. Sometimes they modify it to make it better. And as the project progresses, you can see if your code actually does what it was meant to do – add a feature or fix a bug. That’s the exciting part! Keep going.

Since that first commit, I’ve made one more to help with the skip link in Underscores. I’m sure it won’t be my last, and I know I’ll learn much more along the way.

Need a Menu on Top in Accessible Zen?

A few weeks ago Nicolas Steenhout, a user of Accessible Zen, sent me a tweet with a request I knew would come sooner or later.

He wanted a menu area on top of Accessible Zen. So I built a child theme to accommodate! :) It’s part of my Accessible Zen Theme Pack, available on Github. It features a menu area in the header plus a keyboard-accessible features. Check out the Accessible Zen Top Menu Demo. Older browsers, like Internet Explorer 7 and 8, get the desktop layout because they do not support CSS 3 Media Queries.

View the Accessible Zen Top Menu Demo.

I’d love to know what you think!

Happy blogging!

Updates to Accessible Zen Since 1.0

Since Accessible Zen hit version 1.0, a lot has happened. I’ve released three minor updates, and added a child theme to the Accessible Zen Theme Pack.

Version 1.0.3 of Accessible Zen should hit the WordPress Theme Repository in the coming days. The changelog has all the details. The theme pack includes a child theme called Accessible Zen Dark. It features a light on dark color scheme that passes WCAG 2.0 standards. You can also check out the theme demo for a closer look.

Happy blogging!