Léonie Watson has posted a very well-written article explaining what “semantic” means in the context of the web, along with some demonstrations. It’s worth a read for anyone who’s making things on the web, (including people who don’t consider themselves developers), and it can serve as a quick reference to file away for later when you’re in the middle of building and you need a reference.

Don’t get me wrong. I’m not against upselling. I use the Genesis framework, after all, and I use a lot of premium plugins in my work. These guidelines aren’t addressing upselling in general so much as “in your face” upselling within the WordPress.org directories, along with crippleware. Both crippleware on .org and obtrusive upselling are bad for the community, in my opinion. I’m of course not saying that everything should be no charge, all the time. But WordPress.org is where new users get their start with WordPress, and if we nickel and dime them to death, we’re leaving a bad taste in their mouths.

As someone who builds websites, works on themes and builds custom plugins for a living, I’ll be the first one to tell you that a good website is an investment. But I also remember what it was like to come across WordPress for the first time, and at that time, I wasn’t looking for something to invest in. I was looking for something that would solve a very specific problem, and I had no idea where things would go from there. I think that’s where all new users of WordPress.org are, and for a lot of the users who continue there, building a top-notch website isn’t what they’re looking for. They’re looking for something to play with, something to help with a hobby, or something to put up a quick and dirty website that doesn’t look like it escaped from the 90’s and that they can add features to through plugins. Eventually, if they decide to become full or part time developers, they’ll switch to paid plugins and themes for a lot of their clients, depending on budget. But I think we as a community need to work hard to make sure that WordPress.org doesn’t become a vehicle for turning people away from WordPress the project and WordPress the community. These steps by the theme and plugin teams are definitely in the right direction.

Don’t do that.

For one thing, you’re reinventing a wheel that’s worked well now for a very long time. For another, you’re creating more work for yourself. And finally, it’s bad for accessibility, which effects a lot of users, and I don’t just mean blind ones.

The following video illustrates what can go wrong when you decide to reinvent the UI elements wheel.

If I shouldn’t build my own elements, what can I do instead?

The easiest way to get accessible UI elements is to use already-existing elements under the hood. HTML already provides the elements you’ll need, (radio buttons, checkboxes, comboboxes, and the like), and if you opt for already-existing elements instead of building your own, you’ll be saving yourself a lot of time, and you’ll be working smarter, not harder, to build your application. Which means you can shove it out the door faster, make a lot of people happy, and probably save some money too. What’s not to love.

so the next time you’re tempted to build your own elements, ask yourself:

• What am I gaining by building a custom element that I wouldn’t get by using an already-existing one?
• If I build custom elements, I may be making my application or plugin harder to use for non-developers. Are all the extra support questions and complaints worth it?
• I’m spending more time, and therefore more money, on my project because I’m building custom elements. Is the extra cost worth it?

I think, if you keep these questions in mind when starting to build your user interface, and if you answer them the way I think you will, you’ll have enough justification for sticking with what works before you even bring accessibility into the picture. And if you are inclined towards making the web a better place for everyone regardless of ability, that then becomes icing on the cake.

A Second Opinion

Sina Bahram of Prime Access Consulting, a firm specializing in universal design and accessibility, disagrees with the above opinion and offers the following instead:

I recommend we do not phrase accessibility as something antithetical to what many developers do regularly. I try not to tell developers to deviate from their existing practice, but instead try working with them on improving their existing methodologies to make their creations more inclusive to all audiences. If any developers are interested, I am happy to discuss when custom UI components are appropriate, and how to then make them fully inclusive. Semantic markup, reuse of existing controls, and adherence to solid web development principles are great things to keep in mind when developing novel interfaces. When the need and desire for innovation arises, it is important to realize that new interfaces have the same potential to be fully accessible as current native ones, but it takes a little bit of extra work. I’m happy to discuss further. You can reach me at @SinaBahram on Twitter or
via any other means found at my contact page.

If any other accessibility authorities wish to add their opinions, feel free to ping me and I’ll be happy to add those as well.

This article was originally posted at A List Apart, and generated a lot of very thoughtful and insightful comments. It has since been taken down, and re-posted at Heather Burns’ site. It’s always a sad thing when big-name web publications sensor in order to avoid or deflect controversy.

Digital legislation is confusing and outdated—Heather Burns shows how professionalizing the web industry can help.

Source: The Perfect Storm in Digital Law

This entire article is worth a thoughtful read, and I think it has implications for not only those of us who work as web professionals generally, but accessibility professionals in particular as well.

Specifically, the accessibility profession is going to have to join the greater web profession in working towards a solution to the problems outlined here, and in order to do that, it’s going to have to become a lot less insular. It’s going to have to learn to play well with the greater web community, regardless of whether or not that community as a whole has signed onto accessibility as a right and obligation.

In other words, every one of us is going to have to shelve our pride in whatever we work on and learn to play ball professionally witheach other and other communities who are going to have to come under our umbrella, because we’re up the creek if we don’t get it together.

Back in the bad old days, before the WordPress Accessibility Team really got off the ground and came into its own as a well-loved and respected part of the WordPress project, I used to see a lot of claims from theme vendors, page builder vendors, and plugin authors, (both free and premium), that their products were accessible, or sec. 508 compliant, or the like. Thanks to the work of the accessibility team, and its individual members, that is no longer the case. Not only are plugin and theme authors less likely to declare their products accessible without asking someone to check it, (or paying for work in some cases to ensure that their products are in fact accessible), the term accessible has been more or less swopped out for accessibility-ready, meaning that you can create an accessible site with it, but there’s also room to make your site less accessible by not following the author’s recommendations for settings. All of this makes me very proud. We’re making progress towards full inclusion for everybody, regardless of ability or language spoken, and we’re also making sure we point out where we still have room to grow.

Some of Adrian’s techniques from the linked post above will work in this ecosystem, and some won’t. But either way, this is a great roadmap for users who are either downloading or purchasing premium products to test claims of accessibility if any are made. The testing technique, and the filing issues technique, are also great ways for users or other developers to help the process of “make accessible all the things” move forward. Just make sure you’re polite and respectful when filing reports. The difference here, as with other open source projects, is that the majority of the time, these developers are putting their free time into these projects, and do not have dollars to spend on proper accessibility consulting or remediation.

Since PHP 7 is shiny and new, it unsurprisingly got a lot of coverage. If you’re migrating from PHP 5, or considering doing so, this talk will let you know what to expect. It also gives some brief information on the grace periods which have been extended to the 5 branch, including specifics on PHP 5.5 and PHP 5.6.

https://www.w3.org/WAI/gettingstarted/tips/