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.

Read ( )
The trend under discussion in this long read is very real and results in all sorts of problems, including metric tons of technical debt and support costs. this is what happens when what I’ll call Shiny Object Syndrome takes the place of good decision-making.
Read New 5.0 Target Date

Based on the stability, testing, and reports on the release candidates for WordPress 5.0 so far, we are now targeting Thursday December 6th for public release and announcement. 5.0.1 will open for commits soon, and will be an area people can choose to focus on at the contributor day at WordCamp US …

For those of you who are reading this in your inbox, the context for this post is the recently-published, (as in yesterday), target release date for WordPress 5.0, which rolls out the new Gutenberg editor. I’d like to say I’m surprised by this, but I’m just not. I find myself asking a few questions: First, I find it very difficult to believe that a piece of software that is being released with known, significant issues, (up to and including significant accessibility issues, and no, that doesn’t just apply to assistive technology users), can be declared stable enough for release. Accessibility problems, just by themselves, are bugs. Well, they are if you claim to consider accessibility a priority. Next, if the plan was to release the Thursday before WordCamp US, (and I have to concur with those who believe it has been), what was the point of all those one-on-one office hours? How is anyone in the WordPress community supposed to believe that Matt is dealing in good faith when he has apparently convinced himself of the superiority of his own definition of quality and stability, and that his cause is so right and so perfect that it’s worth literally sneaking a major release out the door while everyone is traveling to WordCamp US? I am not opposed to the concept of Gutenberg, and I never have been. I know the current editor is not perfect, and that it can be improved. But this whole thing wreaks of fanaticism, arrogance, dishonesty, a complete disregard for any standard definitions of quality control, (there’s no way, absolutely none, that enough time for actual testing, complete with stress cases, could have been performed between RC 2 and RC 3, and that’s not even counting RC 1), a complete disregard for those of us who work with WordPress users outside of what is apparently a hermetically sealed bubble of perfection in which Matt lives, and the day-to-day experience that has informed our comments since day one, along with a healthy dose of hope as a strategy when it comes to Gutenberg. The question and answer session at this weekend’s State of the Word address is going to get interesting, as is the dev chat this Wednesday.

This post originally started as a Twitter thread. Since those can be difficult to read in some circumstances, and since this content is I think valuable for more than just WordPress Twitter, I’m spooling it up and re-sharing as a complete post. I’ve also added a link and a video to this.

OK third-party WordPress, we need to have a come to Jesus meeting about your accessibility flare. The day I hoped and prayed would never arrive, and which I feared would get here despite my wishes, is here. People and organizations who choose WordPress because of its power and flexibility, and yes, because it can often be easier and less expensive to use than creating a custom solution, are being served with demand letters regarding the accessibility of the websites they build. Websites they build with our themes and our plugins. I have two clients in my cue right now, both within a matter of days, who find themselves in this position, and they’re lawyers have already responded to the demand letters agreeing to terms. This is good for business, for obvious reasons. But it does not make me happy at all. Not one bit. The fact is, I want people to build accessible websites because it’s the right thing to do, not because they have to be sued into compliance or bullied into same. We, as software creators, have a responsibility to ensure that we don’t put them in this position, whether the plugins they use or the theme they use are premium or free. The resources are out there for you to learn how to write accessible code and how to design accessibly. Trust me, this is not some sort of “Hey your stuff sucks, hire me and I’l help you fix it” marketing campaign. I want you to fix your stuff, regardless of whether or not I get anything out of it. I want people who use WordPress to be able to rest assured that, when they build with our stuff, they are building things that are inclusive of everyone, without having to ask. I want people to be able to build accessible websites without having to hire someone who specializes in accessibility to do it for them. I do not want some momblogger to be served with a demand letter, only to find that the site they built with a $100 theme and some free plugins is now going to cost them thousands of dollars any way they cut it. The only people who really win in these senarios are the lawyers sending the demand letters. There’s consequently a backlash brewing in the legislature, which if successful, will further punish people with disabilities by restricting the already-limited solutions we have for resolving accessibility complaints. And make no mistake about this, people with disabilities are not at fault for wanting their civil rights to be upheld. Accessibility is a civil right. This talk explains.

WordPress now powers close to 30% of the web, or even if you don’t like that stat, still a sizeable portion of it. With that kind of reach comes responsibility. We can say all we want that it’s the responsibility of the people building the websites to look after accessibility. That’s fair when the only people building websites are web professionals. But web professionals are far from the only ones building websites. We, as people who build for WordPress, are not responsible for what any other platform does. But we are responsible for what we do. And we build plugins and themes like it’s going out of style, which people then download and use to build websites. We have an obligation to ensure that we don’t expose them to risks like this without their knowing it. In a lot of these cases, if some small organization or business gets a demand letter, their only recourse is to take the site down, since they could never afford to spend thousands of dollars on a custom website in the first place. That means their voice goes silent. We are in the business of democratizing publishing. That also extends to building the actual website. And the thing is, this is completely unavoidable, and by unavoidable, I don’t mean in exchange for people with disabilities putting their civil rights on the back burner. This situation should not be happening, and we, as the creators of this software, have an opportunity to help stem some of this, and a responsibility to do so. I am serious. I do not want to see another urban clinic, or another non-profit, or another momblogger, served with a demand letter and faced with a bill in the thousands of dollars for fixing it because they chose WordPress instead of a custom solution. Of course, I will fix sites, switch out plugins and themes, ETC. But this is not the way accessibility should be mainstreamed. Bringing the legislative hammer down on people with disabilities is not the answer. Waiting on the Department of Justice to get its act together and settle this is also not the answer. But third-party WordPress, this game where accessibility is a nice-to-have or an afterthought is over. With or without my help, start getting your crap together. Seriously. And yes, Envato, this especially includes you, because let me tell you what’s happening. Someone wants/needs to build a website, and so they go looking for the perfect theme. So they google, and they land on ThemeForest, and find the perfect theme with all the right features, pretty demmo, all that. They then buy it and set it up, caring nothing about proper theme architecture, bundling plugins, none of that. And then, they get served with a demand letter or lawsuit. And they don’t care how the theme was built/what makes up their website. They care that they were able to spend $50-$100 and have a presence on the web. And Envato, the majority of those sales are going to you and your authors. So I do not care if you have to make a mandatory rule stating that no theme can exist on your site without following the WordPress theme accessibility guidelines, do it. I don’t care if you then have to take those theme guidelines and apply them to the front end of the plugins your authors bundle in. Do it. Obviously this goes for the rest of you too, but Envato is huge in this. So once again, get your crap together, do your f*cking jobs, so your users don’t walk into this unaware.

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.

Pippin Williamson wrote a thorough and balanced review of page builders for WordPress that I would encourage everyone to read, whether you’re an end user or developer. He touches on accessibility a bit, but I wanted to go a bit further down that road, and didn’t want to write a novel in his comments. And so, this post.

First, WordPress is not to blame for page builders

Page builders, (and also website builders), were a thing long before WordPress entered the scene. WordPress is just putting its own spin on this trend. I can’t deny that there’s a huge market for page builders, no matter how much I dislike them. And let me tell you, that dislike is strong. I believe page builders and website builders are a huge contributing factor to the mostly inaccessible web we have today. I also firmly believe that, if you are going to create websites, you have a responsibility to at least have a general grasp of how the web works, what HTML is for, ETC., before you start creating websites. Yes, I know that sounds very elitist. But if you buy a car, you either have to maintain it yourself, or pay someone to do it for you. That option exists for websites too, but if you’re not willing to pay someone to build your website for you, then it’s your responsibility to learn how websites are built, and to then build them properly.

OK, page builders are here to stay. Now what?

Having said all of the above, I’m well aware that this battle is lost. So the next best thing, (if we’re stuck with page builders), is to ensure that users can’t do things like use HTML and CSS incorrectly without trying. If we’re going to give non-tech people the ability to build websites, then it’s the job of developers, (especially the ones who make page builders), to ensure that they do things correctly by default.

Cascading Stupid Developer Tricks

At this point in time, none of this is happening. Page builders create some of the worst markup out there. Some of them allow users to go in and change the markup, but this then defeats the purpose of a page builder, and given what page builders promise, (do all the things to build a website with no code), I can’t believe anyone seriously expects that users are going to go “Hey, this is horrible markup, let me go in and fix this”. And so we end up with a web that is inaccessible by default, and not just because of the developers who build websites, but because of the users who use page builders to build websites. I’d be willing to bet that the latter group far outnumbers the former group.

If you can’t, or won’t, ensure that end-users deploy standards-compliant markup and proper CSS, then you have no business releasing a page builder. It’s that simple. To do so without making it extremely difficult to build non-standards-compliant websites is completely irresponsible. If we’re going to give people the ability to build websites without learning HTML and CSS, fine. But that means that the companies behind all these page builders need to ensure that their developers, and designers, know their stuff. That means being familiar with standards, including WCAG, because it’s not a nice-to-have, it’s part of the package. Web designers and web developers breaking the web is bad enough. Don’t encourage people who want to build websites and are not designers and developers to further break it. Those of us who build the web ought to have enough respect for it to at least try to make sure that the things we build function correctly, and provide user experiences that work for everyone. To do otherwise is unethical on top of irresponsible, and makes us look like amateurs instead of professionals.