Where we develop robust web sites with emphasis on accessibility
Amanda wearing a blue knit cap
#WCUS Every day is a good day for web standards.
I’m spending Contributor day working on some accessibility fixes to the Indieweb Publisher theme, which I will submit as a pull request when done because I need some easy wins if the WordPress accessibility fight is going to continue.
I’m also celebrating Blue Beanie Day early because every day is a good day for web standards.
It has been a while since I wrote out some thoughts on where the Indieweb is on WordPress. Sitting here, after hearing Matt Mullenweg gave the State of the Word at WordCamp US, and after I assisting Tantek Çelik in his talk on Taking Back the Web, which was one of the contributing factors to my being at WordCamp US.
#WCUS I’m glad that @RianKinney asked that question regarding accessibility and other policies.
It would be so cool if we could treat #a11y as an “everything-is-awesome” moment and not as a must-do.
Problem with that approach was aptly illustrated by Gutenberg being released in an inaccessible state.
I’d like to say I’m surprised we’re apparently still doing this despite $31,000 worth of audit, but I’m not.
Yes, it would be totally awesome if we didn’t have to say “you must” with regard to accessibility, but unfortunately the makers of the web have consistently demonstrated that that is literally the only way anything gets done.
For the first few years of my career as an accessibility practitioner, I worked on a series of projects whose final reports heavily focused on only the positive, including asking testers with disabilities to talk about what they liked, even on seriously inaccessible sites.
That approach wasn’t just partially ineffective, it was one hundred percent ineffective.
Absolutely none of the sites reported on were fixed, or even improved.
Those sites are still broken.
That’s what happens when you spend your time objecting to accessibility must-dos because they’re must-dos instead of realizing that, yes Matt, there really are things that developers and designers have consistently demonstrated they will not do unless you basically force them to do those things.
All of this also goes for privacy and codes of conduct.
In short, WordPress.com would need to support at least two of the Indieweb building blocks:Webmention and full Microformats 2. See all the building blocks at the first link.
In order for WordPress.com to be a turnkey solution, it’ll need to support these things out of the box, and make it as simple as checking some boxes, or better yet, turn them all on for everybody by stealth.
part of this involves themes, and for the time being users either have to install a plugin like MF2 from the WordPress repository which will try to programmatically add Microformats 2 to a theme, or choose a theme that has full Microformats 2 support already baked in, or manually add them to a theme themselves.
I’m not saying WordPress.com couldn’t do this, (I’d love it if they did, and if they became a turnkey solution for people who want to join the Indieweb), but I don’t see that happening any time soon.
#WCUS Question: Do you find it easier to read websites/pages that are multicolumn or single-column?
It doesn’t matter to me as a screen reader user, because everything is always a single column, but I’m thinking that if a page is one column, never-ending scrolling can become an issue.
On the other hand, there could be a reason that multiple columns could also be an issue for people who use their vision to read.