Mindmapping Is A Great Way To Generate Blog Posts Quickly, And Now You Can Mindmap Accessibly

My friend and colleague Bob Dunn wrote a post on generating blog post content by mindmapping a couple years ago, and when I first saw the post, and read through his tips and techniques, I have to admit I became slightly jealous. OK, very jealous. I couldn’t figure out how to adapt the strategy to make creating mindmaps accessible, and so I believed this was something I just couldn’t use and that I’d have to stick to other strategies for creating blog content. To add to the jealousy, Bob is the king of CoSchedule, which means he’s really great at taking his old content, writing new headlines for it, and then sharing it multiple times on social media. This was also not helping my jealousy problem.

This morning as I was browsing through my personal Twitter feed, I came across a post on Blind Bargains in which Tangela Mahaffey reviews a mindmapping app called MindNode 5, available on iOS. Because this is Blind Bargains, accessibility plays a huge role in whether or not something gets reviewed or even posted. If it’s not at least reasonably useable by blind people, Blind Bargains doesn’t cover it.

When I encountered this link in my Twitter feed, I was thrilled. It meant that I would be able to take advantage of a blogging technique that I had reluctantly set aside, and it meant that I could start freely sharing Bob’s post on mindmapping because there’s now an accessible way to do it.

The Blind Bargains post reviews MindNode 5 extensively, going through each step of the process to set up and use the app while using VoiceOver for iOS. If you’re a blogger, or if you want to blog, I strongly encourage you to open Bob’s post in one tab, and Tangela’s post in a second tab. Then, start fitting Bob’s techniques into this app. Mindnode 5 is definitely on my wishlist of apps for iOS, and I can’t wait to get started using it.

Custom Entry Message Boxes: Some Quick Accessibility Considerations

There’s a quick tutorial on custom entry message boxes on the StudipPress blog, and because I think this could be a useful addition to a site for things like affiliate disclosures, I’d like to offer some accessibility considerations.

Look out for color contrast

When adding the example CSS to your theme, make sure the colors for links inside the message, the bottom border color, and the various message color schemes don’t introduce color contrast issues into your theme. You’ll want to make sure there’s appropriate contrast between the message foreground and background, as well as apropriate contrast between the message and the surrounding text. You may also want to include a style guide somewhere on your site explaining the significance of each colored message, and add that link to your custom message.

Make sure the importance of the message isn’t communicated by color alone

When adding your custom entry messages, make sure that the importance of the message isn’t communicated by color alone. You can accomplish this by prefacing each message type with a word or series of words indicating its importance: “Important”, or “very important” or “urgent”, for example. You’ll want to make sure you don’t make these indicators visible to just people who use screen readers, since people who live with color blindness or cognitive disabilities also need to know the information you’re alerting everyone else to.

Custom aentry message boxes can be a useful addition to some types of websites. If you’ve never planned for accessibility before, they can be a great place to start developing that habit, since they’re a simple customization. It doesn’t matter if the rest of your site is accessible at this point. These messages are a great place to start making improvements, and to borrow from the philosophy of Breslov Hasidism, one accessibility improvement paves the way to another, and you should make as many accessibility improvements as you can, even if you can’t improve everything at once. Finally,

The work is not for you to finish nor are you free to desist from it.

Mishnah, Pirkei Avot (Maxims of the Sages) 2:15-16

In Defense of the #a11y Hashtag

There are some accessibility issues you could call evergreen. One of them is whether we should use the #a11y or #accessibility hashtag when spreading the good word on the social medias. Mosen Consulting shared a post in which Mr. Mosen holds that

… the use of the #A11Y numeronym, a hashtag sometimes used on Twitter to group accessibility-related tweets together, lessens the impact of tweets on a subject that is critical to the independence of many of us.

I would like to respectfully disagree and challenge this viewpoint, in favor of the #a11y hashtag.

Firstly, hashtags may have started out as a way to conveniently group social media posts, but they quickly became a marketing tool. At this point, they’re about branding. The word “Accessibility” means different things in different contexts. So those of us concerned about accessibility as it pertains to making things useable by people with disabilities need to be able to distinguish between “accessibility” as a general term and “Accessibility” narrowly defined in the specific way we’re concerned with. The #accessibility hashtag doesn’t do that. The #a11y tag does.

Secondly, people more often than not interact with social media on their phones. That’s one of the reasons numeronyms became a tool among various groups of professionals on social media. Other examples include #i18n (for internationalization), #l10N (for localization), and conference names beginning with just their initials in a lot of cases instead of the entire name. Previous character limits also played a role in this. But between convenience and previously-existent character limits, #a11y wins the game whereas #accessibility creates a barrier to entry.

Thirdly, the #accessibility hashtag might have been able to gain a hold if it had been campaigned for back in 2010 or 2011 when this all started. But by 2013, (when Mosen Consulting first raised the issue), #a11y was already entrenched. That’s only a three-year difference, but three years in social media land is like thirty years everywhere else. At this point, using #accessibility instead of #a11y would be separating ourselves from the community of practice, and this community is small enough that it really can’t afford that kind of split.

If it’s newby confusion you’re worried about, people who are new to accessibility are going to be confused no matter which hashtag is used. Whether you explain what a numeronym is, or whether you explain that “Accessibility” has a specific meaning when it comes to people with disabilities that doesn’t have anything to do with the other meanins, you’re still explaining.

Finally, dropping the #a11y hashtag would negatively effect other related hashtags, like #gbla11y. This one would, (at best), need to then become #GBAccessibility, or #GBAccessibilityAwarenessDay. Either of these are very long to type on a mobile device.

As long as we’re talking about confusion among terms, I think we ought to drop the term “Accessibility” altogether in favor of inclusive design. Inclusive design goes further when it comes to addressing the needs of everyone, including people with disabilities, and there’s no ambiguity around the term. We could even go with the #iDesign hashtag. As long as we’re keeping “Accessibility” though, I think it’s best not to further muddy the waters with what I would respectfully call a localized version of the “tabs versus spaces” argument.

WordPress Widgets: A Comprehensive Guide

To one extent or another, widgets are part of most WordPress sites. They’re typically added and rearranged by dragging them around and then dropping them where you want through either the “Widgets” screen or the Customizer in the administration side of your WordPress installation. Along with the drag-and-drop interfaces in both the main “Widgets” screen and the WordPress customizer, there’s also an accessibility mode for controlling WordPress widgets that isn’t very well documented.

In this guide, I’ll give you a brief history of how WordPress widgets came to be, document the “Widgets” screen’s accessibility mode, show you how to add and arrange widgets on your site, provide some tips on widget placement when you don’t have perfect vision, and discuss the fundamental shift that is coming to WordPress and how that will effect WordPress widgets.

The What and Why of WordPress Widgets

WordPress widgets are self-contained areas of a web page that perform a specific function. They were created to allow WordPress.com users to customize their sidebars without touching a line of code. After an overwhelmingly positive response by WordPress.com users, WordPress widgets became a WordPress plugin. Widgets became a core WordPress feature in version 2.2.

Two years after WordPress widgets were introduced to core, accessibility mode was added so that keyboard users and people with disabilities could control the widgets on their sites. Accessibility Mode was one of the WordPress project’s first forrays into web accessibility, having been added to core about three years before there was a dedicated accessibility team.

Although they were originally developed to help customize just the sidebar of a theme, WordPress widgets are now used to build the home pages of many premium as well as free WordPress themes. They are an indespensible tool for building WordPress websites, and you can get pretty far without knowing any code by using them. So let’s go through how to add and configure them accessibly, step by step.

Activate accessibility mode

From your WordPress dashboard, select the “Appearance” submenu, and within that submenu, select “Widgets”. Once you’re on the “Widgets” screen, expand the “Screen Options” tab by pressing enter on it. Press enter on the “Enable Accessibility Mode” link. Collapse the “Screen Options” tab by pressing enter on it again, and you’ll return to the mane “Widgets” screen.

An Overview of the Widgets Screen

When you enable “Accessibility Mode,” the appearance of the “Widgets” screen changes significantly. The first thing you’ll encounter once you’re in the main content area of the screen is a heading at level one that says: “Widgets”. Directly under the “Widgets” heading is a link to manage them in the customizer with live preview. Ignore that for now. We’ll discuss using the Customizer in a later post. Below this link, you’ll find any administration notices currently visible on your dashboard.

Next, you’ll find a heading at level two containing the text: “Available Widgets”. Directly below this, you’ll find a link with the text: “Add”, folowed by the widget title. All widget titles on this screen are contained in headings at level two, and below each title is a brief description of what the widget does.

How many widgets?

The number of widgets you have on this screen depends on the widgets your active theme and active plugins have added. Both themes and plugins often add their own widgets since they’re so integral to customizing WordPress sites. Each widget will have its own configuration options on the add-widget screen.

Below all the available widgets, you’ll find a heading at level two with the text: “Inactive widgets”. This section stores any widgets you’ve previously used, in case you want to resume using them along with the configurations you’ve set. There’s also a “clear inactive widgets” button you can use to empty this section. Clearing inactive widgets deletes them permanently from this section along with their configurations, so if you visit this section after you’ve cleared it and find you need to use one of the widgets you previously stored here again, you’ll need to go through the process of re-adding and reconfiguring it. Each widget title in this section is wrapped in a heading at level three.

Below the “Inactive Widgets” section, you’ll find each of your theme’s widgetized areas with its title wrapped in a heading at level two. Above each widget title in this section, you’ll find a link with the text: “Edit”, followed by the widget title. When you press enter on any “Edit” link, you’ll be taken to the widgets configuration screen where you can make and save changes. The number of widgetized areas depends exclusively on your theme. The name given to any widgetized area also acts as a brief description of that area. Below each “edit” link, you’ll find the widget title wrapped in a heading at level three.

WordPress’s Default Widgets and Widget Configuration

Aside from the widgets provided by your active theme and plugins, WordPress comes packaged with several default widgets. I’ve listed all of the default widgets below, and, (because I’ve been around the WordPress block a time or two), any experience and/or opinions I may have about each one.

  • Akismet Widget: Display the number of spam comments Akismet has caught. In my experience, this widget doesn’t have a practical use. Displaying the number of spam comments caught is merely a vanity metric, and is not likely to increase the trust of your site’s visitors.
  • Archives: A monthly archive of your site’s Posts. This widget is useful if you run a blog with a lot of excellent content that people may want to re-visit.
  • Audio: Allows you to easily display an audio player without knowing HTML. This widget is useful if you’re a musician and you want to showcase tracks you may have for sale.
  • Calendar: A calendar of your site’s posts, in a data table. In my experience, this widget also has no practical use, since a site’s visitors won’t typically browse a site’s posts by month.
  • Categories: A list of links to all of your site’s categories, (excluding any attached to custom post types), or a dropdown, (combo box) of all of your site categories, (excluding any attached to custom post types).
  • Custom HTML: Allows you to add text marked up with HTML. This widget is infinitely useful, in my opinion. It often forms the backbone of the text on home pages, and is also useful for things like displaying banners, badges, one-time advertisements or advertisements controled by a third party, site announcements that don’t merit their own blog post, the list of possibilities for this widget is close to endless.
  • Custom Menu: Allows you to add a WordPress menu to areas of your site without those areas needing to be defined as menu locations by your theme. This widget is useful if your theme is stingy about navigation menu sections.
  • Gallery: Provides a graphical user interface for adding a gallery of images to a widgetized area on your site.
  • Image: Provides a graphical user interface for adding a single image to a widgetized area, including any image attributes such as alternative text and captions.
  • Meta: Login, RSS, & WordPress.org links. In my experience, this widget is also useless in practical terms. Most sites will not want to display links back to WordPress.org, and I’m not a fan of displaying a log-in link on the front-facing portion of a site for anyone to be tempted by. This last bit could just be me having a get-off-my-lawn moment.
  • Pages: A list of your site’s pages. This widget could be useful, although it displays a list of every page on a site, and I recommend adding important pages to your navigation menu instead.
  • Recent Comments: Your site’s most recent comments. This widget is useful if you run a site that gets a lot of user engagement in the form of comments, typically large blogs.
  • Recent posts: Your site’s most recent posts. This widget is useful if you’re using a static front page as your home page, but you want to highlight recent posts in a side bar.
  • RSS: Entries from any RSS or Atom feed. This widget can be useful if you run more than one site and want to quickly display content from that site on another site.
  • Search: A search form for your site.
  • Tag Cloud: A cloud of your most used tags.
  • Text: Allows you to add any text to a widgetized area using the standard WordPress content editor. The aim of this widget is to make adding arbitrary text easier for those who don’t know HTML. The custom HTML widget was added after enough of us expressed our displeasure at having our favorite widget contaminated with a WYSIWYG editor. This widget also supports adding an image to a text widget, using the “insert image” button in the editor tool bar.
  • Video: Displays a video from the media library or from YouTube, Vimeo, or another provider.

Common Configurations Among WordPress Widgets

Every widget has configuration options specific to it, but there are parts of every widget configuration that are the same no matter which one you’re adding or editing. Each screen will ask you to choose the following:

  • Widgetized area: Labeled as “Sidebar”, this refers to any widgetized area of your theme, including dynamically generated pages.
  • Position: The position of the widget you’re adding within the widgetized area. Each area commonly has two positions, although I’ve seen situations where there are more than two.

All the widgetized areas and their positions are displayed within a table. Select the radio button for your preferred area and choose the position of the widget from the combo box below the radio button you’ve selected. Once you’ve chosen the widgetized area and the widget’s position within that area, save your configuration choices by pressing the “save” button. If you’re editing a widget, and you want to delete it, press the delete button without changing any configuration options instead. Your deleted widgets will then appear within the “Inactive Widgets” section until you clear the section of its contents. After you’ve added or edited your widgets, you’ll be redirected back to the widgets screen after you press the “save” or “delete” buttons. If you decide while editing or adding that you’ve changed your mind about the widget, there’s a link labeled “Cancel” directly above the “Save” button. Press enter on that and you’ll be redirected back to the widgets screen and your changes will not be saved.

Some Tips On WordPress Widget Placement

When adding widgets to your site, there are some things you’ll want to keep in mind as a visually-impaired or blind person. Firstly, not only does your theme define what widgetized areas are available, it may also style specific widgets. Alternatively, a theme’s CSS may need to be modified to accommodate a widget the theme has no styling for.

Secondly, widgetized areas themselves will be styled, and this will determine which widgets may be suitable for a particular area, even if the theme doesn’t require specific styling for the widget. It can be helpful to read through your active theme’s CSS to get a sense of what’s going on visually. This is why I prefer the Genesis framework and its child themes when building sites for myself or for clients. The CSS is very well-organized and well-commented, which makes it easy to read.

If you’re not sure about how a widget is going to look with your theme, ask for help. The help you need could be as simple as someone advising you on a more suitable area for the widget, or as complicated as someone customizing your theme for you. Be aware that the former can be readily had for free, while the latter will cost you. Any investment on your part will be necessary though if you’re selling products or providing services to the public. A well-designed website is just as important as the clothes you wear to a job interview. If it’s your personal blog and you want your sighted friends to read what you’re writing, then design also matters, if for no other reason than avoiding a poor user experience for your sighted visitors. It doesn’t have to be anything fancy. It just needs not to be an eyesore. Finally, when you change themes, you’ll need to go back in and edit your widget placement. The new theme you’ve chosen may have different widgetized areas, and/or the widgets you used with your old theme may be part of the theme itself. If they’re part of the theme, they’ll disappear from your available widgets once you deactivate the theme by switching to the new one.

Change is coming to WordPress, and this will effect WordPress widgets

Before wrapping up this guide, I want to talk a bit about the changes coming to WordPress in the near future, because they will have an effect on WordPress widgets. The changes I’m referring to are code named Gutenberg, and the goal of the project is to change the way content is created in or added to WordPress. This includes widgets. The aim of the Gutenberg project with regard to widgets is to make them portable, meaning that they’re no longer dependent on widgetized areas, and can be added to anywhere on a site. This will help site owners more easily create dynamic pages, for example. In the future, it will also mean that wordPress doesn’t need to maintain three separate interfaces for controlling widgets: The customizer, the main widgets screen, and accessibility mode. It will mean that site owners wil be able to add widgets to their sites accessibly while taking advantage of the same interface that everyone else gets to use, thus eliminating the separate-but-equal status of assistive technology users. Widgets will become portable, so site owners won’t necessarily need to worry about reconfiguring widgets when they change themes. All of this is in flux, and is not slated to be released until it’s ready. There are accessibility kinks still being worked out. But Gutenberg promises to be a better experience for everyone, and despite my current concerns, I’m fully on board with the idea. It will, however, mean some adjustment for those who have been using WordPress for a while. The content creation experience, (including editing and controlling widgets), is going to become richer, and initially there will be some discomfort on the part of those who are used to the old way of doing things. Because those of us who are blind or visually impaired have never had complete access to the way the rest of the world does things when it comes to creating sites, I think the jump will be initially hard to make, because we’re going to need to get comfortable to a whole new set of concepts we’ve never experienced before. But I’m looking forward to the challenge, and I’ll be updating this guide so that you’ll be able to navigate them as well.

Widgets have been a staple of customizing WordPress sites for a long time now. This guide should help you more confidently experiment with them to make your site your own creation. There are as many widgets as there are WordPress plugins and themes, so there’s a lot of variety for you to explore when customizing your site, all without touching any code. Go forth and build cool things.

Gleanings From Mozilla Festival 2017 With Transcriptions Of Screenshotted Text

Conferences with social media hashtags are great, because those hashtags mean that you can still glean from them even if you can’t attend. It can also be overwhelming when there’s so much goodness happening on a conference hashtag that you want to share everything you find. There’s also the problem of all the great content being generated on one social network essentially being locked into that network as long as we’re only sharing it on that network. So I’ve decided to start sharing the cool stuff I find from various conferences as blog posts. That way everyone can take advantage of it whether they’re on a particular social network or not, and I can avoid filling up people’s timelines with reposts. I can also take the liberty of providing screenshotted text in text form so that everyone can read it.

Here are my gleanings from MozFest. MozFest was born in Barcelona, Spain, in 2010. Originally named “Drumbeat,” the festival convened a community of people dedicated to learning, freedom and the open Web. Each year MozFest centers around a particular theme, and this year’s is the health of the web as a whole, (spoiler alert: It’s not good), and how we as contributors to the web can improve it. Everyone is a contributor to the health of the web, not just the people who make the software that powers it or allows people to access it or allows people to easily create content for it. This year, MozFest consisted of nine floors of talks, workshops and exhibits. Once the speaker talks are available somewhere other than Facebook Live, I’ll share some of those as well, in separate posts.

All of the content I’m sharing is publicly available within the constraints of Twitter or Facebook. I’m sharing it in the order I read it. I’ve also transcribed any screenshots I’ve shared. I’ve shared directly from the social networks, so you have the opportunity to share on your own timelines if you want, without copying and pasting. Enjoy.

Meet this year’s Mozilla Festival speakers.

Only 20% of the world, primarily white folks, are
editing 80% of Wikipedia’s content—that’s kind of
telling. Together, we realised that most of our
collective understanding of the world is still being
written by a minority.


What we need are companies that are
not advertising platforms, to make
browsers — the basic tech of the net.

Mishi Choudhary

Have a security policy. You can think of it like the
things you are already doing to be digitally safe.
Maybe this is where it all begins.

Matt Mitchell

Digital inequality is just as bad
as any inequality.

–Alan Knott-Craig

To be digitally safe as an organisation, you need
to think of a checklist. It is a matter of time until
something happens… This checklist saves
people. If anything happens, you know what to

–Matt Mitchell

Making a healthy
Internet is not a spectator

–Mark Surman

More products include software inside them to be
updated over time, but practically the support to these
products ends a lot sooner than the companies are
willing to provide a warranty for the product—which is
probably insane.

–Ugo Vallauri

“I think all of us are feeling [an] urgency….You have
instability—I have been thinking about the need for
knowledge, the need for inclusion, the need for the
power and potential of the movement.

–Ryan Merkley

The Trump Administration thinks that letting some
telecom companies treating some content more
favourably than others is a good thing. Think about
how these companies treat it already. It could not be
any worse

–Ashley Black

You’ll now detox one of the browsers you use on your computer (you’ll clean up your mobile browsers
later, on Day 5). By the end of todays detox, you should be blocking a lot more information from trackers, and this in turn should make your browser less unique – since there’s less information to form a
The devil’s in the default “Privacy Settings”
No browser’s default privacy settings are actually private by default: most store cookies, as well as
your browsing history, webform entries and other information-which can then get shared.
But Chrome, Firefox and Safari all offer a special “Private” or “Incognito” browsing mode, set to
automatically delete your browsing history, cookies, temporary files and webform entries every
time you close the browser. Note: your bookmarks and downloads are not deleted.
Try it out:
1. Open your browser (Firefox, Chrome or Safari) and go to File -• New Private/incognito Window
(depending on the browser).
2. To set Private Browsing permanently in Firefox or Safari, go to:
Firefox: menu>Preferences>Privacy>settings for history

Note on this transcribed screenshot: The last bit of text at the end is too garbled for me to make out and correct, but the steps listed above are still useful. There will be an online version of the data detox kit coming soon, and as soon as that’s available I’ll link to that instead.


Designing For Inclusion With Media Queries

Inclusive Design 24 (ID24) is happening again on November 16, and I can hardly wait. If you’re not aware of what ID24 is, it’s twenty-four hours of free talks on accessibility and inclusive design. Each talk runs for about an hour, and the entire event lasts for twenty-four hours straight. I told myself I wasn’t going to stay up for twenty-four hours again at the end of the last event, but now that it’s happening again I’m seriously reconsidering that, because it’s so much fun and there’s so much stuff to learn and cool people to engage with using the #id24 hashtag on Twitter.

In anticipation of ID24 happening again, I thought I’d share my favorite web-related talks from past events. The one I’m sharing today is “Designing for Inclusion with Media Queries,” and it was given by Eric Bailey. Eric is a Boston-based user experience designer who helps create straightforward solutions that address a person’s practical, physical, cognitive, and emotional needs using accessible, performant, device-agnostic technology. You can find him on Twitter as @ericwbailey and you can read more about his work at ericwbailey.design.

I’m Participating In The Ultimate Blog Challenge This Month, And I Think You Should Join Me

For me, one of the best parts of the web has always been blogs. They’re an expression of the web as it was meant to be, at least in one aspect. Open and independent. Somehow we all got sucked in by the convenience of social media, and while social media has meant that it’s sometimes easier to stay connected, we’ve traded a lot in exchange for that ease of connection, and most of it isn’t good. But more on that in another post.

What’s a blog challenge?

Put simply, a blog challenge is setting yourself a goal to write a blog post at least once a day for a certain number of days. The one I’m participating in this month is called the Ultimate Blog Challenge, and I’ll be shooting for thirty-one posts in thirty-one days. It starts today, and you still have time to join if you want to participate. Once you sign up, you’ll get an email each day with blogging tips and prompts. You can either use the prompts from the emails, or chart your own path. There’s a Facebook group you can join to share your posts and read posts from others, along with a Twitter hashtag: #blogboost. If you’re participating, make sure to comment on other people’s posts. It’s a great way to build community and relationships, and it’s also part of the rules.

What if I don’t have a blog?

If you don’t have a blog yet, why not start one? It doesn’t matter what platform you use or how technical you are. If you have an old blog, why not dust it off? And you don’t have to write three hundred words every day. It’s perfectly fine to write a short post, or just share a photo with its caption. You could even use the challenge to begin to own your data, or just get a writing habbit going. Microblogs also count.

I’m not sure if there’s a point at which you can’t sign up anymore, so I’ll encourage you to give it some thought, and if you’re going to join, do it as soon as possible. Even if there’s not a closing date for sign-ups, the sooner you join, the less you’ll need to catch up. So give it some thought, and come press publish with the rest of us. It’ll be fun.

Are HTML And CSS Still Valuable On Their Own? Abso-friggin-lutely

There’s a post going around web maker social media that deals with the subject of HTML and CSS being undervalued, to the point that people who only write HTML and CSS, or even people who don’t write JavaScript, have no value in this industry, and how we desperately need to change that mindset. It struc a chord, and I have some related thoughts. Well, more like a related rant, because although this attitude is one that’s being talked about as if it’s new, the truth is it’s not special to JavaScript, but more on that later.

Money quote:

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.
Mandy Michael

In case you were wondering, we have a long, long way to go before we get to the point where every single website meets the qualifications I quoted above. We’re not even close. Wanna know why? Crappy HTML, and crappy CSS. That is pretty much what this whole accessibility thing comes down to, at the most basic level. People who use assistive technology can’t use ninety percent of the web because crappy HTML and crappy CSS. You have trouble using your phone to browse the web when it’s sunny out on your back porch because crappy CSS. If you pay me to audit your WordPress theme or plugin, the overwhelming majority of the issues I’m going to flag have to do with the way your PHP and JS are creating HTML and you’re using crappy CSS. Wanna use ARIA for your controls? Guess what it does. Extend HTML. And this isn’t a JavaScript-specific thing. They’re far from the first to be of the opinion that HTML and CSS aren’t important or are less valuable than the latest fad. This idea is almost as old as the web itself. PHP shares this attitude in some quarters. So did every other community building something that was supposed to be the be-all-end-all of creating things on the web. I’d even venture to say that this attitude was prevalent for a very long time in the WordPress space, and the further you get from the inner circle of the WordPress community, (the one percent, if you will), the more prevalent this attitude is. But HTML and CSS are critical to how the entire web works, and unless you learn them to underpin your JS and your PHP or whatever other web technology comes along in the future, we will continue to have a broken web, and it’s only a matter of time before you, personally, have to deal with the consequences in a way that you can’t change by simply changing your surroundings. Seriously, don’t wait till it gets to that point. Learn HTML and CSS properly so that we all have a web to use no matter what the circumstances. Learn HTML and CSS properly so you can build page builders with graphical user interfaces that anyone can use to build things for the web that work for everyone. Don’t shift onto the shoulders of your users the task of playing whack-a-mole to find accessibility problems and then making the extra effort to report them to you in the most diplomatic way possible, because that takes a metric ton of energy and emotional labor, and every single person with a disability should not have to be an accessibility advocate. Don’t continue to foster a situation where there are entire platforms where you can’t build or use a website while using assistive technology, only to then be possibly told that if you want to be able to do so, you might have to vote on it as a feature, and hope you can get enough people together to convince some CEO somewhere that this thing that is part and parcel of how the web was intended to work that he’s now considering an enhancement is something he really should fix on his platform. It’s not enough for only some platforms to be accessible. Every single one of them should be, by default, and getting there requires that anyone who calls themselves a web developer learn HTML and CSS, even if that means you have to stop what you’re doing with the latest sexy thing on the web so you can go back and learn them.

I could probably boil all of this down to “Don’t be a jerk.” But “Learn HTML and CSS” is the one thing that the accessibility community has been saying for years and years and years and years, and if we were to turn this into a drinking game, (every time you have to correct some developer’s HTML or CSS, take a drink), we’d all be dead from alcohol poisoning. And it’s incredibly disheartening to ponder where we might be if everyone who ever built anything for the web had learned its foundational technologies properly. So, go learn HTML and CSS deeply, and quit devaluing these technologies by your words and actions.

The Next Time You’re Thinking About Threading On Twitter, Write A Blog Post Instead

If you spend a lot of time on Twitter, you’re probably familiar with Twitter threads. They show up in your timeline because either someone quotes or retweets someone else’s threaded tweet, or, if you’re lucky, you see all the tweets in the right order because (a) someone takes the time to thread them properly by sending one tweet, and then replying to the original tweet with the rest, and (b) you either follow the threader, or their account is public and you have it on a list, so you see the tweets as they come in. If you’re on Facebook or some other social network, and one of your friends wants you to see the thread, they’ll share one of the tweets from the thread in the hope that you’ll click on it and read it. But Twitter threads are not good for all sorts of reasons, and because I feel rather strongly about the subject, I decided to write a ranticle about it.

Why do people thread in the first place?

People thread on Twitter because Twitter’s 140-character limit is almost never enough when you really need to get something off your chest. Also, Twitter, (including third-party applications), has an incredibly simple posting interface without a lot of distraction involved. The fact that you can use a third-party app on your phone which may have an even simpler posting interface, through which you can fire off tweets at the drop of a hat, makes it even better. When you add up a 140-character limit, plus a really simple posting interface, it’s easy to see why Twitter threads have become as popular as they are.

Still, I would like to discourage you from Twitter threading. In the strongest possible terms.

Threading might be great if you’re the one posting the content. I use the word “might” because whether it’s great for you or not is debatable. But if you’re trying to read it, that’s an entirely different story. For one thing, it takes a lot of time and effort to scroll back through tweets, and that’s assuming you’ve stumbled on the original tweet that started the thread. If not, you’re stuck in the hell that is Twitter’s user experience trying to scroll back through tweets. If someone quotes a tweet in your thread, the thread is now broken, which makes the effort needed to put into reading an entire thread much more involved. It means that you might have to spend more time in Twitter’s horrible user experience hellscape trying to find out where the thread begins because someone quoted in the middle of a thread. Second, since Twitter threads are by their nature chunks of ideas, it’s realy difficult to cite a thread in such a way that keeps all the comments in context. Since tweets are now making up a large part of what gets reported by news outlets of all stripes, that means this has become more important, both for those reporting the news and for those reading it.

Next, there’s the problem of linking to this content. Since each tweet has it’s own link, and that link is based on a user ID, linking to all the pieces of content that make up a thread is somewhat like collecting individual rice grains once you’ve dropped the bag of rice. Not easy. And depending on how many tweets are in the thread, (I’ve seen threads of over 300 of them), a metric ton of work.

Then, there’s the part about how the content you create is yours and not some corporation’s. There are a lot of good ideas floating around Twitter, (and other social networks for that matter), but as long as that content is being posted on Twitter and nowhere else, you don’t own that content. If Twitter decides to change its link structure, that content may be lost.

This is important for people, but it’s also important for businesses. Posting your content on Twitter in the form of a thread, (or really, on any social network), instead of your website means you no longer own that content. It’s like going and setting up a stall at the local flee market and calling it your office. You’ve invested time in creating that content, you should own it. It should have a permanent link that won’t change unless you want it to, and which anyone can link to. Then, you can syndicate that content to Twitter, or Facebook, or anywhere else you like, and even if someone isn’t on any of those networks, (believe it or not, there are people who don’t use social media, and have no desire to start using it), can read and benefit from your content.

But what if I’ve already threaded on Twitter?

Fortunately, there are some tools you can use to collect all the parts of your thread and turn them in to blog post for later linking and enjoyment. Spooler is an excellent choice for converting Twitter threads into blog posts. You can start with the last tweet in a thread, and it will also grab any videos and images you’ve posted to Twitter that are part of the thread. If you find that you’re live-tweeting a talk or something similar, Noter Live is a great option which will, (once you’re done tweeting), allow you to copy all your tweets from the event into one post, along with including the speaker’s Twitter handle if they have one. If it’s the feedback you’re after, you can always enable webmention on your site. Popular web platforms like WordPress and Drupal have plugins to do this, and you can use a service like Bridgy to syndicate your content to the social networks, and then pull in reactions and responses to your own site so you have them all in one place, coupled with the content you created.

While I’m pretty certain this one post isn’t going to stop you from threading tweets, I hope that you’ll consider the people who are reading the content you’re creating, and instead of creating a thread that’s not even enjoyable to read on Twitter, you’ll at least consider turning it into a blog post afterwords.

Replied to

I know I’m very late to the party after a tiny bit of research I’ve done so far. I’ve seen the same names pop up all over the place. These folks have worked very hard to get where it is now and I’m sure they know of dozens of roadblocks I couldn’t imagine today. But, I hope that, even if I’m late, there’s still room at the table.

Source: The Open Web, by Brandon Kraft

It’s never too late to join the indieweb. The more people who join, the better, and I would personally love to see all the indieweb technology become part of WordPress core and/or Jetpack. And I think the point of the indieweb is that everyone shouldn’t just rent their seat at the table, but own it.

This is the most accessible implementation of webmention and reactions I’ve seen so far. The little faces have alt text associated with them, (the names), and all the reactions are identified, with their post kind. Now I need to get this set up on my own sites. 🙂

tumblr Hands Automattic And WordPress A Golden Marketing Opportunity By Blocking Logins From Eleven Email Providers

Starting on June 30, 2017, att.net customers will no longer be able to log in to their Yahoo and Tumblr accounts through email addresses with the following domains: att.net, ameritech.net, bellsouth.net, flash.net, nvbell.net, pacbell.net, prodigy.net, sbcglobal.net, snet.net, swbell.net, and wans.net.
If you’re affected, all you need to do to ensure continued access to your Tumblr account is to update your registered email address to something other than one of these addresses mentioned above.

Source: Tumblr’s Helpdesk

The help article then goes on to tell people how to update their registered email address. Neither self-hosted WordPress, (or even WordPress.com), care what email address someone uses to log in, once that email address is associated with an account. And you can definitely create Tumblr-style sites with either platform. If you use self-hosted WordPress, you have even more options for adding features to your site thanks to plugins. There’s at least one plugin that will import all your Tumblr posts into your WordPress site, keeping them intact.

This really wasn’t a necessary move on the part of Tumblr. There’s no technical reason why someone’s email host should matter. A lot of these people have probably had these email addresses for a very long time, and to ask them to go get another one from somewhere like Gmail just so they can log into and use your service is wrong on every level.

Gutenberg, Week Two: A Working Analogy For Blocks, And Some Questions

If you're playing along with those of us who are taking the Gutenberg Challenge, this is my post for week two. This time, I'm using the text editor. I decided to go with the text editor this time because it's slightly easier. Sorry WordPress, not even you can win the WYSIWYG VS. text editor war. 🙂 As with the first post, these are my not-so-edited thoughts.

First, a working analogy for blocks

I spent some time mulling over this throughout the weekend, and I've decided to settle on the following working analogy. Part of this is because I cheated and looked at some of the code, as well as the generated markup. This will probably also work for widgets. So let's say that you have a bunch of magnets in different shapes and sizes. With widgets, your shapes and sizes are pretty uniform, and widget areas in themes are like metal surfaces you can stick them to. I'm thinking of a toy I got as a kid that was a big metal board/frame/rectangular surface, with letters that had magnets on the back so you could make words on the board but with the letters raised. Yeah, it's incredibly simplistic, but it works. With the introduction of Gutenberg, WordPress is just going to magnetize everything, and the pile of magnets now includes letters, numbers, special characters, punctuation, and every other shape under the sun. OK. So far so good. I think though that this has the potential to make web pages/other web things pretty much fluid from a design perspective, protean even, and I hope there's an upper limit somewhere. Something like, let's try to educate people about design principles, because hamburger menus inside posts, and I would like to reserve some things for the CSS/HTML realm. I know we're democratizing publishing and everything, but democracies have rules. Not sure what I think of this wp:core/freeform tag, which basically means we're using a text widget to add text to a post. I'm keeping an open mind, but it seems to me as though WordPress wants to create its own

tag, and that we've definitely stepped into overengineering territory. After all, it's just text, HTML already has tags for this, (tons of them), and if this is for possible styling later, we're just trading div soup for non-standard WordPress self-created tag soup. So yeah Gutenberg, we're not friends yet, but I'm not kicking you out either. I'm missing my meta boxes though. My screen seems so lonely without them. So I'll be heading back over to my tried and true edit post screen to put the finishing touches on this, and you can hang out down here in your little submenu, well away from my other content types for now.

Some Thoughts On Building a blogroll in 2017

Those of you who were around in the pre-Web 2.0 era (before 2005-ish) will remember that early bloggers used to have a list of other blogs they read in their sidebars. That list was known as the “blogroll” and it was a great way for newbies to get to know established bloggers. The other neat thing about the blogroll was that it was a token of respect to the bloggers you admired.


Blogrolls used to be a thing in WordPress, except WordPress refered to them as “Links”, and you managed them using the Links Manager. I think there’s still a working plugin for this, and if you’re like me and you’ve had a long-running WordPress installation, the links manager is still in your administration panel. I think blogrolls got an amused mention last weekend at WordCamp Europe as well, but I have to agree with the post I’m quoting. they were a fun part of the web, and I’m thinking that, they really should be brought back. I used to have quite a full blogroll, and yes, I made a point of reading most of them every day. Mine specifically didn’t have a lot of news sites on it, just blogs, mostly personal ones. I’m not saying that news sites couldn’t be listed, (the cool thing about blogrolls was that you could list whatever you wanted, and other people could see what you were reading), but I always liked to keep mine more personal and less edited.

There’s a site called WPRoll that I think still lives, but it seems to be more of a list of influencers. There is, however, an OPML file you can get that has all the blogs, that you can then import into your RSS reader. I’ve done this, and for the time being I’m using the WordPress.com reader, because it’s the most accessible one that I’ve found that I can also use on my phone.

But yes, we should definitely bring blogrolls back. The web, and the world, could use a little more let’s-get-to-know-each-other, and that’s what blogrolls provided.

Gutenberg With A Screen Reader: Initial Thoughts And Reactions

Last weekend, during WordCamp Europe, Matt Mullenweg announced that Gutenberg, (the upcoming WordPress editor that will replace TinyMCE as well as become integrated into the WordPress customization experience), is now available for downloading and testing. So of course people have started playing with it, and Aaron Jorbin issued the following challenge on Twitter today.

The Gutenberg Challenge

I broke my own cardinal rule and installed this on a live site, because I need content to play with. I'll start with the good first. I appear to be able to add blocks and move them around using the visual editor part and a screen reader. Now for the not so good.

I can type a post title, but I have to add a block just to start typing text. I can see myself switching to text when this goes live, because writing a post like this is turning out to be incredibly inefficient, cumbersome even, and I'm not sure if that's because I'm just used to writing HTML and can do that in my sleep and so I don't use WYSIWYG editors, or if it's because of the software, or both. I'm also not sure if paragraphs are supposed to be in their own separate blocks although I suppose if you're going to be moving them around, they probably should be each in their own block. I can see this increasing the cumbersomeness exponentially. Right now I'm thinking of what it would be like to write one of the WordPress with a Screen Reader posts in this and I want to just crawl under my desk and never write again. I've lived in the WordPress dashboard daily since 2005, and I'm finding this really frustrating. I can see someone new to WordPress who uses a screen reader just giving up on this. Admittedly, as I mentioned above, this could all just be I'm not used to using a visual editor like this. I also realize that this is only six months along, and that it's in its early stages. I'll also continue to play with it so I can get used to this, and then explain it to other screen reader users. But I think I'm going to end here for now because this is completely overwhelming, I'm unable to separate my own experience from what's supposed to be happening and be fair and objective about this, and, (I'm only half joking here), Gutenberg is causing me to question my life choices right now.

You Know They’re Scared When They’re Resorting To “Two Guys In A Garage”

Recently, I was told by more than one person who had a private meeting with VFO salespeople at CSUN 2017 that the guys trying to sell JAWS are telling those who buy enterprise site licenses that “NVDA is just two guys working in a garage, if they’re hit by a bus, the whole thing disappears.”

NVDA: Now More Than Ever!
I’d like to talk a little bit about the “two-guys-in-a-garage” argument. Chris goes on to demonstrate why it’s completely false in NVDA’s case. But even if it were completely true, it’s still one of the most short-sighted arguments that can be used against FLOSS. “Two-Guys-In-A-Garage” is the argument you make when you have nothing else. You can’t prove that your functionality is better, so you try to argue in favor of scarcity.

We’re at the point where Jaws for Windows, (the so-called best-in-class screen reader), is aping NVDA, (its FLOSS rival), in order to stay relevant. This is especially evident when it comes to the web, where NVDA shines and where Jaws for Windows continues to lag behind. And unfortunately for VFO, (the parent company behind Jaws for Windows), the web their screen reader struggles with is the thing that’s eating the world. Everything is going web. It’s not just pages anymore, it’s applications now too. And Jaws for Windows can’t keep up with NVDA in this arena.

I, like a lot of other people in this community, was devastated by the news that Window Eyes is being discontinued. But NVaccess and the rest of the NVDA community are providing us with the freedom and choice that the big player believes they have the right to take away from us, and this is very heartening. So NVDA, you keep being you and doing what you do best, because when VFO crashes and burns, I want to be first in line to dance on its grave with a drink in both hands.

I’d Like To Talk To You About ARIA Abuse From A Screen Reader User’s Perspective

When WebAIM evaluates a client’s website for accessibility, we often spend more time evaluating and reporting on ARIA use than any other issue. Almost every report we write includes a section cautioning against ARIA abuse and outlining ARIA uses that need to be corrected or, most often, removed. Ironically, this is often followed by a list of issues that can only be addressed with ARIA.

WebAIM – Web Accessibility In Mind

This quote gets to the heart of my own love-hate relationship with Aria. As a screen reader user, I’ve seen abuses that make me want to strangle developers. I think the worst abuse I’ve ever come across, (and I’m sorry I can’t find it again to provide a demonstration of it), was one where role=”alert” was used to deliver advertisements and calls to action on a website. And it definitely did. “Alert! Buy our stuff! Alert! Download our e-book! Alert! sign up for our mailing list! Alert! Here’s this cool article you should read about whatever hot marketing tip! http://something.something/keyword! Alert! Here’s this other cool thing you should read!” Every few seconds. I have no idea whether the site’s developers or owners or marketers were specifically intending to advertise to screen reader users, or whether they were just trying to get past ad blockers, and I don’t care. All I know is, that site enraged me more than any comments section ever could, and I couldn’t close the window and file it under “Places You Never Go on the Internets Ever Again Under Any Circumstances” fast enough. WordPressers, do not ever do this. If you build sites for clients in any capacity, do not ever do this.

Admittedly, what I’ve recounted above is an extreme case. I’ve never come across anything like it again since. I’m recounting it though because what we as web professionals and hobbyists do on the web has a real impact on people, positive or negative. Whether that impact is positive or negative is solely dependent on us. We can make the web a place for everyone to enjoy and learn and be entertained and obtain things, or we can make it a place that people want to stay as far away from as possible. It’s up to us.

Some Tips For Screen Reader Users Who Want To Take The WordPress Editor Experience Survey

During the 2016 State of the Word, it was announced that the wordPress editing experience would go through a complete redesign. As part of this redesign, the WordPress project is currently conducting a survey to find out how WordPress users experience and use the current editor. This applies to self-hosted WordPress, not WordPress.com.

Feedback from all users is important, not just from users who are advanced or who are completely familiar with how WordPress works, or who don’t use any assistive technologies. I’m taking the survey myself, and below I’ll outline some tips for screen reader users to be aware of so that taking the survey is as easy as possible, whether you’re an advanced screen reader user who spends his or her days scouring the internets, or not.

The first thing to note is on page two of the survey, where there are two sets of radio buttons. If you’re using NVDA, don’t tab through this screen. All the radio buttons have labels, but once you’re done tabbing through the first set, you’ll still be in browse mode, and focus will move to the second set. The question relating to that second set will not be in the tab order. If you do choose to tab through this screen, exit browse mode once you reach the second set of radio buttons.

The second question on page two refers to the markup editor, and is accompanied by a screenshot. The markup editor is the text or code editor.

The third question on this page is also accompanied by a screenshot, and “these buttons” refers to the series of buttons above the content field in the text editor.

On page five, instead of radio buttons or checkboxes, there are a series of comboboxes inside list elements. Page six asks a series of questions specific to screen reader users, and one of them asks if there are any accessibility issues you may be experiencing with the current experience. This applies to either the text or visual editor, and the text field will allow you to enter a lot of detail, so I would encourage you to do so. There’s also a question that asks if you use other assistive technologies along with a screen reader, so if you use multiple assistive technologies, make your voice heard. The last page is a couple of open-ended questions with standard edit fields for you to enter information.

I hope you find these tips useful, and that screen reader users make a point of taking this survey. WordPress’s mission is to democratize publishing, and screen reader and other assistive technology users are just as much a part of “everyone” as those who don’t use any assistive technology. The feedback you provide through this survey will help WordPress ensure that the new editor is accessible to as wide an audience as possible, so if you have the time, and you use a screen reader along with WordPress, I hope you’ll consider taking this survey.

Reviewing 2016

2016’s been a bit rough around here. Three close friends have died, two from cancer and one of them in a car accident. Two of those deaths happened recently, less than a month apart, and I’m still unpacking those. But there’s also been an amazing amount of awesome this year too, and I’ll detail that below.

2016 Achievements

I haz the props!

One of the goals I set for myself in review of 2015 was to contribute code to WordPress core. In March of 2016, I received my first WordPress props, and in April of 2016 I was recognized as part of the motley crew of contributors to WordPress 4.5, otherwise known as Coleman. This was a huge achievement for me because I’ve pretty much been a WordPress evangelist in both my personal and professional lives since 2005, and it was really awesome to earn a spot on the WordPress credits page.


DictationBridge, before it even had a name, began when Pranav Lal, Lucy Greco of UC Berkeley, and I started working together to discuss making a free addon for $750 just to bring a license current. I can’t be the only one in this situation, and I don’t believe anyone else should pay up to 68% of the retail price as a penalty.

In July of 2015, Chris Hofstader joined the team to take over the executive role on the effort. Together, Pranav, Chris, Lucy and I built out the amazing team of fourteen that’s bringing DB to the world.

In August and September of 2015, Pranav and Chris tried to negotiate a licensing deal with a group in Germany to use their code as the core of DictationBridge. The German group wished to maintain proprietary source code which was a deal breaker for DB, as we were committed from the start to the values of an open source project. Chris then called Mike Calvo and they negotiated an agreement that permitted Serotek to license the dictation code from its SystemAccess screen reader in a manner compatible with our philosophy that a blind or otherwise disabled person should never be forced to pay a penny more than anyone else to use the same technology. The agreement with Serotek made history as it’s the first time a vendor of proprietary closed source assistive technology software has agreed to open up its source in exchange for a very modest licensing fee.

The next bit of history we made happened when the Lighthouse for the Blind and Visually Impaired of San Francisco made an official endorsement of and large monetary contribution to the DictationBridge campaign. Quoting Brian Bashin, CEO of the SF Lighthouse, “The Lighthouse believes it has a moral obligation to support the access needs of blind and visually-impaired people wherever they live.” During the discussions between the DB team and our friends at SF Lighthouse, one of the major goals we set was to ensure that a blind person in an emerging nation could buy a cheap laptop at a flea market and have full access to dictation features built into Windows, a goal we’ve never heard expressed by a large organization in the blindness space before. By collaborating with SF Lighthouse, the DictationBridge team built what we hope to be a long standing bridge between those of us in the free software community and at least one well established advocacy organization.
The nature of the DictationBridge team is also a first of its kind in the blindness business. The team is made up of people from two businesses (3 Mouse Technology and Serotek), a number of independent contributors and a coalition of activists in the blindness and technology world. The team has a number of members for whom dictation is a requirement and not a feature and we’ve some of the strongest engineering and management talent available in the world of accessibility. Assembling an ad hoc team like this one on which everyone works toward a common goal is unprecedented in this field.

Both of these achievements helped add some awesome to a year that I couldn’t be happier to see on its way out. I haven’t nailed down next year’s plans yet, but they will definitely include more contributions to WordPress, and, hopefully, more projects like DictationBridge. With DictationBridge, we’re fast approaching the first public beta. And there’s still plenty left to do. Free software hasn’t eaten the assistive technology world yet, and this is something that can’t happen soon enough.

For right now, those are the only goals I have for 2017. I’m still working through what I want to accomplish as far as my business is concerned, and more importantly, a plan of action for accomplishing it without killing myself in the process. So for now, I’ll say a hardy goodbye to 2016, and as far as 2017 is concerned, bring it on.

WordPress, Web Accessibility and Web Development Roundup for December 18-31 2016

This one covers a rather long period of time, (see: the holidays), and there’s also a lot of heavy reading in it. Not all of these posts are technically recent, and I’ve made a point of including things that are a bit more out-of-the-way and that aren’t featured on the big sites like Smashing Magazine or CSSTricks. Not that I don’t like those sites. It’s just that I assume that most of us already have their content coming to us through their feeds or social profiles. And, like music, the best content isn’t the stuff that gets released for air play. It’s everything else on the album. Enjoy.


Why WordPress removed the underline button from the visual editor.

BobWP on WooCommerce Connect, a neat little plugin I haven’t yet had the chance to play with yet.

Pagely has a guide for the WordPress community on SSL, which is becoming rather more important now that Google’s seriously gunning for plain old http. Tim Nash has an even more in-depth guide to SSL that’s suitable regardless of whether or not you use WordPress, and has become my favorite to pass around.

There’s a cool little plugin that clones sites within a WordPress multisite network.

Carrie Dils with a pretty neat guide to using staging sites on WP Engine, which I’ve used for the last two years and still managed to learn from this guide. Maybe it helps when someone else writes it down. 🙂

You can, and therefore should, control the activation of your WooCommerce extensions so that you don’t confuse users of your plugin.

Web Development

Some pretty epic criticism of that “best-developers-are-always-hacking” tweet:

Joe, people are angry at this tweet. Can you guess why? Perhaps it’s the implication by you, as a CEO, that anyone not working over the holidays is not good enough?

A really enjoyable read about building a really fast website from the developer’s perspective. Lots of ego in here, but also lots of humor.

Improving site performance while using gifs gives a brief history of the file format, as well as the promised site performance tweeks.

Creating shapes with CSS, and then going further to create more advanced shapes.

Upload files to your raspberry pi from anywhere using a browser.

An introduction to local and session storage in JavaScript.

Web Accessibility

Dennis Lembree has a few things to say about parallax design, the issues it can cause for a slightly-larger-than-WordPress-sized market share of people, ending with a reading list of further resources on just about everything he covers in the short article that I would encourage everyone to read, especially designers.

Cristopher Broyles offers some insight on how data analytics can be used by businesses to improve their digital accessibility.

Some well-deserved praise for the W3C for leading the charge toward a fully inclusive web from the American Foundation for the Blind.

A tutorial on building accessible modal dialogs by Paul J. Adam on the Deque Systems blog. Definitely keep this in your toolbox.

Mailchimp has some quick tips for creating accessible email newsletters, and I for one hope that this means they’ll start working on the user interface they provide to create those newsletters so that it’s accessible too.

WooCommerce has a post about the importance of accessibility for online stores, which includes some tips and links to free tools you can use to get started with making your store more accessible, thus potentially gaining more customers.

Some very useful information on accessible emoji by Léonie Watson with a solution for displaying the contents of the aria-label attribute to users with vision by Adrian Roselli, who wanted to make sure the playing field was level and included people who don’t always understand what the emojis mean.

I’ve covered a lot in this week’s round-up, but if you think there’s something not included that should be, feel free to leave it in the comments below.

In an effort to ensure I can find things later, I’ve decided to begin compiling a weekly roundup of WordPress, web accessibility and web development posts. So, welcome to the first edition. For now these are in no particular order.

Tony Gines on designing user interfaces for my mother.

As designers and developers, it’s our responsibility to make our websites not only useable, but enjoyable enough to come back to again and again.

Patrick Roland on how to be a better human, as a wrap-up of this year’s WordCamp U.S.

Karl Groves on chasing the accessibility business case, which is the conclusion of a series of posts on the topic which is worth the read and is something I always come back to for review. The main takeaway from the post is that the best argument in favor of accessibility that any business can use comes down to one word: quality.

Yoav Weiss on contributing to Chromium and the web platform itself.

Firebug is going away.

Sixty Minutes takes some of the worst examples of disability rights lawyers and sets them up as the only examples, shutting down any meaningful meaningful community-specific discussion about what is and what is not ADA trolling in the process.

Adrian Roselli on how we reward the wrong things when judging the quality of websites

Faith Macanas provides some greate starting advice for WordPress site owners by laying out some questions you should ask before adding an eCommerce plugin to your site.

Nick Hams on the true cost of bargain basement WordPress themes. I couldn’t agree more.

There’s a lot to read for this edition, so I’ll end it here for now. Enjoy, happy reading, and come back next week for the best finds from the WordPress, web accessibility and web development worlds.