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

the WordPress widgets screen
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.

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.

–SIHO BOUTERSE

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

–Matt Mitchell

Making a healthy
Internet is not a spectator
sport

–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
“fingerprint”,
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.
https://twitter.com/hennazb/status/924229826617147392


https://twitter.com/Audesome/status/924265970516090885

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


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

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.