Replied to

This is an incredibly glib response to the issue of why people or products haven’t jumped on the Gutenberg bandwagon.

I’m sure I’ve already raised several objections to this strawman explanation but I’ll continue to do so every time it gets raised by Matt.

Speaking for myself, I’ve been using computers since before there were true screen readers. I’ve adapted with every single change to that piece of software alone, to say nothing of operating system changes and application changes and even WordPress changes since 2005. I promise you, this is not about being afraid of change. And I seriously doubt “afraid of change” is the case for even half of the rest who haaven’t aadopted Gutenberg.

As of June 9, 2021, Gutenberg is still an efficiency and useability nightmare, despite the technical accessibility improvements that have happened over the last two years or so. I see this every day with my own usage, John’s own usage, (and he’s got just as much or even slightly more experience with computer usage than I do), with clients who use assistive technology of any kind, and even with clients without any disability who don’t spend all their time living in their WordPress dashboards.

I have a single client who truly does enjoy Gutenberg, and that’s because their only familiarity with using WordPress was through visual composer.

I’m not saying, and I’ve never said, that WordPress should never change. I get that WordPress needs to adapt, I get that it needs to modernize, and I have no problem with any of this.

What I have a problem with is that adaptation being poorly thought through and poorly managed, the complete disregard for tons of completely avoidable problems having been created during almost the entire development cycle of Gutenberg, the prioritization of dreams at the expense of technical realities, (see that whole discussion on GitHub about how Gutenberg is never going to be Microsoft Word on the web no matter how much that’s wanted by product designers), and then the pretense that none of this has happened and that everything is just peachy and it’s all about people just being afraid to change.

If this were really about being afraid of change or unwillingness to evolve, I would have quit using computers cerca 1995 around the time of quite literally a seismic shift in the way screen readers work under the hood and the way they present information to users. Or that other seismic shift in 1998/9 or so when MSAA became a thing. Or that other one in 2006 when Web 2.0 became a thing.

But I didn’t. And that should tell you something.

Replied to Blind people, advocates slam company claiming to make websites ADA compliant (www-nbcnews-com.cdn.ampproject.org)

In an email, Ekerling said people who criticize the company online are largely stirred by “thought leaders” who are rallying blind people in a “huge campaign”
against the company with few specific critiques.
“Almost no one gives any specifics to actual websites that really don’t work for them,” Ekerling wrote in an email. “This is because they don’t really
test us, nor have really used us. At most, they went on a website out of anger and didn’t even try to understand.”

No really, I promise, we’re not just “stirred by thought leaders”. I can state with complete confidence that neither Karl Groves nor Adrian Roselli have gotten in touch with me in any manner to offer beers in exchange for negative comments about AccessiBe. 😛 And really, that’s all it would take, that is, if we must mix in some stirring by thought leaders.

I could be this easily bribed to slam AccessiBe because the product doesn’t solve even half the problems it claims to solve, hell will freeze over before they manage to make the entire web accessible, and Ekerling, at least, is a lying liar who lies.

There. I said it. Publicly. The AccessiBe hashtag on Twitter is overflowing with examples of websites that don’t work, complete with videos of users experiencing them not working. Ekerling knows this. So we’re well past ignorance and well into lying territory.

Replied to Proposal: Treat FLoC as a security concern (Make WordPress Core)

Google is rolling out Federated Learning of Cohorts (FLoC) for the Chrome browser. TL;DR: FLoC places people in groups based on their browsing habits to target advertising. Why is this bad? As the …

I’m responding to this on my own site because I can’t get the interface on the Make blog to do the click right when attempting to reply over there.

I 100% agree with this proposal. Users can only choose to opt in or out if they’re able to make an informed decision about this, and for better or worse, they can’t do that. I’m pretty sure Google will market this as some sort of user-beneficial feature, assuming they tell non-technical users anything at all about this. WordPress, according to its own “bragging”, (I’m using that loosely), powers something like 40% of the web. We can’t continue as a project to pretend we have no impact on it.

Replied to

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.

Replied to A post by Greg McVerry by Greg McVerryGreg McVerry (https://quickthoughts.jgregorymcverry.com/)

@cswordpress @Cambridgeport90 I picked a 5th choice: non WordPress CMS. Still native mf2 support in WPEngine properties would be great. Blocks worry all the PHP folks who have no, and don’t want any, React experience.

This reply is part of a conversation on this post which has carried over to Twitter. There’s an elephant in the room we need to talk about regarding the fifth choice of non-WordPress CMS, and it’s accessibility, (or lack thereof) of those content management systems.

Before anything else, Greg, I’m not mad at you for picking the fifth choice. WordPress isn’t the only thing out there, and it shouldn’t be the only thing out there, if for no other reason than the principles governing the Indieweb basically state that there shouldn’t be one platform/CMS to rule them all. That said, there’s a reason a lot of people with disabilities, (screen reader users especially), choose WordPress, and to a lesser extent, Drupal.

Aside from the things that popularity brings, (one-click installs, for example), the fact is that content management systems outside of WordPress and Drupal and somewhat Joomla! do not take accessibility into consideration as part of their development and design roadmaps. And nobody wants to be the first person to start advocating piecemeal with each and every one of these only to be told that “Accessibility is not a priority” or any of the other excuses put forth for why something isn’t accessible. Nobody certainly wants to do it for free.

I continue to contribute to WordPress accessibility for a whole host of reasons, some of which have to do with self-interest. I use WordPress and I want to give back, and it makes sense for me to invest in the platform that has helped me make my living for the last ten years. I also want others in the blind community to have the opportunity to use WordPress to make a living of their own. In order for that to happen, accessibility has to be part of the project.

And unfortunately, experience has taught me, (as well as others in the disability community), that accessibility just isn’t a high priority, especially if it gets in the way of some cool new feature. That’s true for everything from Cpanel to PHPMyAdmin all the way down the line to just about every other thing used to create websites.

Granted, given the insistence in the indieweb space on semantic HTML, I could find that I am pleasantly surprised that Known, for example, works just fine. And there are good reasons for using it, most notably that indieweb stuff just seems to work out of the box. What I’m not sure about though is the accessibility of themes/templates, and whether or not post kinds display is accessible, to say nothing of the creation process.

Which brings me back to WordPress and Drupal, but especially WordPress. People who use screen readers, and to a lesser extent other assistive technologies, use WordPress because work is constantly being done on accessibility, along with the reasons that draw others to it: One-click installs, lots of options, thriving design/development community to create those options, and (relative) ease of use. And because things like Squarespace, Wix, and pretty much every other open source/free software content management system has significant accessibility problems, plus learning curves and all that jazz.

So, to get back to my contention that indieweb WordPress will have to embrace blocks, I completely get that none of us want to touch React, and believe me I haven’t developed some sudden love for Gutenberg. I just think that, if indieweb stuff is going to take off, it’s going to have to be easier to handle the theming aspect of indieweb, and I think the easiest way to do that is to go with the flow of the community as much as possible. I’m not suggesting that the work be apportioned to others. Far from it. I’m saying we collectively need to do this, not that someone else should do it. I just don’t see the current theme status quo sticking around for long, and right now, we’re forking default themes probably because they are the easiest to fork, Independent Publisher being the exception.

I’d feel sorry for anyone who tried to fork a Theme Forest theme. That’s something I wouldn’t wish on my worst enemy. And Genesis, as much as I love it, is going to take some thinking through due to the changes they’re making, and the fact that generally plugins that work best with Genesis are built to work with that framework and the way it does things and not to be compatible with stuff outside of that. There are some exceptions, (Give, Gravity Forms, anything that uses shortcodes to insert its content). But I think getting something like Post Kinds working with Genesis, plus making sure that it still works with everything else, would be a ton of work. I think there would have to be a separate Genesis-specific plugin to handle post kinds for that framework. And I’m using Genesis as my example because it has 250,000 users, a thriving design community along with development community, and is really quick to set up sites with. Problem is, that community is embracing blocks, because admittedly blocks make some things a lot easier to do, homepages that aren’t just static but are a mix of static and dynamic, for example. Up until Gutenberg that’s been accomplished with widgets and sometimes custom loops. Blocks/Gutenberg eliminates a lot of that work.

So the Genesis community isn’t going to want to go back to the old way, even if indieweb is important to some of the community members. Users aren’t going to switch from Genesis to what’s currently there for indieweb with regard to themes unless they decide to be idealistic above everything else, which means indieweb is adopted by less people overall. While Genesis is the example under discussion here, all of this applies to every other theme framework, and themes in general. In short, blocks is where it’s at, whether I like that or not, and even if I still hate React for all of the reasons I hate it.

Replied to A post from Greg McVerry by Greg McVerryGreg McVerry (quickthoughts.jgregorymcverry.com)

@cswordpress Wow, thanks for pointing this out! Was commenting at organizing meeting that we have a strong presence, especially among people who use screen readers. Would love to learn more about your voice and journey. Maybe make a section here: https://indieweb.org/accessibility?

I agree that there is a strong accessibility presence within the Indieweb community. The focus on semantic HTML is the catalyst for this in my opinion. The backbone of accessibility is semantic HTML, which at its heart means using HTML elements as they were intended to be used. Thanks for making me aware of the accessibility page on the Indieweb wiki. Adding some information there could be useful to others. I’m getting back into the swing of writing things on my own sites again, and I still have several Indieweb tutorials to finish. Tiny steps.