Author Mark Wilkinson Date 9th September 2018 Topics DevelopmentIntroduction
I have been using WordPress for many years – all the way back to version 2.0 in 2005 and I am now co-owner of a WordPress agency, here at Highrise Digital. A key breakthrough for me, in terms of being a WordPress develope…
Bookmarks
storing a link/bookmark for personal use or sharing with others
Adding additional meta boxes, fields, and other information to WordPress is easy if you know the right hooks and the proper APIs to follow. But what if you want to add information to a WordPress taxonomy page?
For example, say you want to create a custom WordPress category edit page or, at the very …
A WordPress plugin that will enable you to register custom menu theme locations and easily swap menus on individual WordPress Pages or Posts.
Late in November, I published a personal opinion on the state of Gutenberg accessibility. Today, I’d like to give an introduction to Gutenberg from a screen reader user perspective.
I still have issues with this whole Gutenberg process, and my recent criticisms regarding leadership and project-level accessibility prioritization still hold.
But this quick guide to using Gutenberg with a screen reader gives me a place to start, and at least allows me to work with the thing, and even to think about experimenting with some things on a development version of this site.
So, thank you tons Marco, I probably owe you a keg at this point. 🙂
Google wants to speed up the web, and it has a plan:
For many, reading on the mobile web is a slow, clunky and frustrating experience – but it doesn’t have to be that way. The Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere. Right off the bat, if you use the AMP project page to get a sense of how capable Google is of doing this right, you may become a little deflated. For starters, it fails on the accessibility front, lacking alt text on images, a lang attribute on the element, controls on its opening video, and sufficient text contrast. It also seems to demonstrate just why we want faster pages by itself weighing in at 44MB over 124 requests, taking nearly 6 seconds to load.
If a client insists on it, I’ll do my best to convince them otherwise, but if they continue to insist I’ll of course implement it because pick your battles (TM).
This has turned out to be a great resource for keeping up with the flaws of AMP though.
Since the landmark Domino’s case, I’ve been having some conversations about web accessibility with people who wouldn’t ordinarily take an interest. Some of these conversations have been productive; others have not. The following is a dramatization based on true events.
I’m still laughing. This is the funniest thing I’ve read when it comes to web accessibility in a very long time.
The Accessibility Inspector provides a means to access important information exposed to assistive technologies on the current page via the accessibility tree, allowing you to check what’s missing or otherwise needs attention. This article takes you through the main features of the Accessibility Inspector and how to use it.
Covers captions/subtitles, audio description of visual information, media players, and other accessibility requirements.
This is the latest, and not last, in my informal series of posts on under-engineered controls. Generally I am looking at the minimum amount of CSS necessary to style native HTML controls while also retaining or improving accessibility and honoring different user preferences.
The following accordion examples are enhanced from a basic HTML pattern of container > heading + sub-container.