53 Resources for Developers & Designers building Blocks for Gutenberg by Birgit Pauli-Haack (Gutenberg Times)
There has been an increase in developer resources around Gutenberg. We collected quite a few here. We’ll update along the way.

This resource from Gutenberg Times looks like it might be a great place to begin with Gutenberg development.

Development note: for the purposes of being able to remember gotchas when developing, I’ve added this development note with this bookmark.

While I’m not sure if this is a function of Gutenberg or not, I needed to manually input the information for the post name but not post excerpt, and I needed to manually input the site name. All of this applies when attempting to parse the information from the URL, which uses the “Parse This” portion of the Post Kinds plugin. This may mean something to look at specifically when migrating that plugin.

I Am Cookie Dough by Allie Nimmons
I was always told I had to go to college. I was “gifted” so learning came easy and I enjoyed it.  From ages 6 to 18, I went to competitive accelerated schools designed to churn out college students. It was a narrow path I’d been set on, without encouragement to explore beyond.

These posts are often times the highlight of my week.

IIS Outbound Rules with gzip compression by JAN REILINK
Saotn.org uses used URL Rewrite Outbound Rules in IIS, to offload content from a different server and/or host name. This should improve website performance. Just recently I noticed Outbound Rules conflicted with gzip compressed content. I started noticing HTTP 500 error messages: Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").. Here is how to fix that error. …

An Introduction to Block-Based Homepages with the Genesis Framework by Carrie Dils
StudioPress just released Revolution Pro, the first Genesis child theme to sport a block-based homepage. In this tutorial, you'll learn how to create one.

Speaking from experience, I know exactly what Carrie is talking about when it comes to widgets being a poor choice, (although the only available one), for homepage layouts. I’ve done more than my fair share of theme customizations and often times those customizations meant hiring someone to redo the CSS. I, for one, will be over the moon when I can fully use Gutenberg and take advantage of block-based homepages.

Blindness Charities And Money, Part 1: The Aggregation by Chris Hofstader
many of the biggest blindness organizations are sitting atop a mountain of cash while spending relatively little on programs for the people they state they are helping.

I would encourage every blind person in the strongest possible terms to read the most recent article by Chris Hofstader and download the data. I would especially encourage the blind people who has been contracted by any of these organizations to do things like build websites or write software to read through this data and then make decisions with regard to whether or not you’re going to work with these organizations and how you are going to price your services based on this data and not the sob stories or excuses provided by these organizations when they plead lack of budget coupled with great need for your services. It’s one thing to suspect they’re screwing you over with no proof. It’s a very different, and bigger, ball of wax to know that they are screwing you over, have proof of it, and then contrast that with the “have a large impact”, “make a difference”, “help the cause”, “we’ll send you referals” kind of language that is so often used when they pitch for things like websites or apps. I will not only be reading through this data myself, but also passing this on to any blind person who has been my student, formally or otherwise, when it comes to WordPress.


I suspect that, as a general rule, open source treats the open web the same way that corporate software companies like Apple or Microsoft treat open source: It’s existence and that there are people to take care of it for you while you do the flashy stuff is taken for granted. As a result of this and many other things we, (at least in the US), have a situation where Facebook and Twitter are treated as the web, and then we’re all subjected to displays of incompetence, stupidity, and grifting that will eventually end up defining any possible laws we end up with when it comes to web things. I’d make grifting a link, but I refuse to link to anything related to Diamond and Silk, or any of the completely willfully ignorant comments by Ben Schapiro on this topic. Plus, there’s just way too much material. Fellow hackers, I think it’s time for our typical hands-off approach to anything but our code to end. We have to get involved, because if we don’t, it’s just going to get stupider as we go along, until the stupid gets boring and/or ineffective and it becomes actual malice, assuming we aren’t already to the malice bit. I’m holding out hope we’re still in the stupid portion though because that means we still have time to get off our asses and get involved.

My URL Is is a podcast which features a new guest every two weeks to talk about how they got involved with the IndieWeb and what hopes, goals and aspirations they have for the community and for their website. The guests are a combination of those both new to the IndieWeb and those who have helped build it from the beginning. This episode features Greg McVerry who has been using the web as a teaching tool almost since its inception.

There are a couple of things which stood out to me in this episode. First, the discussion about online versus offline identities. The idea that online and offline are somehow separate is an idea that I think is pretty common, and if I understand Greg correctly, he’s basically saying that there really isn’t a difference between online and offline. I have to agree. In my experience, the separation between identities is usually maintained by people who are particularly rude or trollish to other humans, and then when called on it, come back with, “Oh, that’s just online” or “that’s just Twitter”. Still going with my understanding of what Greg is saying in this podcast, I have to agree. There’s no difference between the online and offline you. If you treat people with little respect online, there’s a good chance you’ll treat those same people with little respect offline as well, and I don’t think the arbitrary separation between online and offline should be allowed to remain.

The second thing I found interesting in this episode is that Greg’s son uses a screen reader to read CSS and other code documentation because he’s in the third grade and therefore reading that kind of documentation is still difficult. I think there are a few things to be gleaned from this. First is the reminder that not all people who use screen readers are blind. I’ve always understood this on an intellectual level but I don’t think I’ve ever run into a real-life non-blind human who also uses a screen reader, so I’m somewhat fascinated and I think I want to pick Greg’s son’s brain and/or watch him work with the screen reader so I can learn if there are any differences between how I use it and how he uses it. Also, out of pure curiosity, I’m interested in which screen reader he’s using.

I think it would be interesting to find out whether or not there might be some room for documentation, (for accessibility related topics and otherwise), that is geared toward a younger and possibly less technical audience. I’m aware of efforts which focus on educating high school students, but nothing for younger generations, and at the risk of coming across as one of those “code solves everything” people, I think we need to focus on groups younger than high school students as well. I have no idea how we solve this.

I’m also curious as to whether or not accessibility as a field could glean something from the generational approach Indieweb takes when it comes to onboarding new community members. This isn’t me trying to start an accessibility fight, or even necessarily criticize what’s come before, I’m just thinking out loud. We know that in order for designers and developers to bake accessibility in from the start of a project, they have to be trained at every level on the intricacies. I think it’s obvious that this is not happening, and I’m not sure the lack of knowledge on the part of designers and developers can solely be chalked up to laziness on their part. OK, I suppose that last is maybe slightly controversial. We also know that people who are not traditional designers and developers are building websites, and, barring the tools they use doing everything possible to output accessible markup and generally guide them through creating things which everyone can use, expecting that they are going to be trained on the intracacies of accessibility when designers and developers aren’t is, I would say, quixotic at best. I think Gutenberg, (the new WordPress editor), can play a role in at least this part of the problem, provided it gets its own house in order and is itself able to be used by everyone.

But anyway, back to the generational thing. The idea behind the indieweb generations is this:

Generations in the context of the IndieWeb refer to clusters of potential IndieWeb adopters in a series of waves that are expected to naturally adopt the IndieWeb for themselves and then help inform the next generation. Each generation is expected to lower barriers for adoption successively for the next generation.

(Full discussion of the “Generations” concept here, with links to other resources.) I see a parallel between this and things like the work that Microsoft is doing through its Microsoft Enable group. That’s not an exact match, because I don’t believe you should build webpages with Microsoft Word, for example, but I think it’s a pretty good template for doing things like making it easier for end-users to make things accessible, and I would like to see this mindset ported over to the web. The important part here though is that they’re also focusing on making it easier for people who use assistive technology to use their products, and I think that’s critical to all of this.

What I’m mostly thinking of though is making it easier for designers and developers to make the things they build accessible to everyone. The work Deque Systems began at this year’s WordCamp US is a really good example of this, and I’m excited to see how this plays out. I think the principle of “Manual until it hurts” also finds a home in the accessibility space, and I believe that ideally designers and developers would do all the accessibility things manually by learning HTML, CSS and the like until they completely understand the foundations of the web. I also know however that we aren’t living in an ideal world, and as much as those of us in the accessibility space scream until we’re blue in the face about learning foundational technologies deeply before learning the stuff that sits on top, this doesn’t seem to be scaling very well. I don’t know why that is and I don’t have a solution for the problem, but it seems to be where we are.

Anyway, that’s all the stuff that bounced around my brain while listening to the third episode of “My URL is”. If you’re interested, even mildly, in the idea of an open, independent web, I think you should check out the podcast.

Prototypes and production
Don’t build prototypes with a production mindset. Don’t release prototype code into production.

I don’t think I’m too far off base to suggest that so many of the problems we face on the web could be avoided if the prototype mindset discussed in this article were limited to the prototype phase by developers and designers, and kept completely separate from the production process.

This Is For Everyone is a talk I will definitely be revisiting, along with all the other talks given so far as part of this year’s Inclusive Design 24, because it’s jam-packed with information, including some very useful statistics. It’s a really good overview of accessibility at a high level, and is a great way to kick off a conference whose talks go into quite a bit of detail about how to make the web more accessible, complete with examples. Hint Indieweb folks, given your love of POSH, (plain old semantic HTML for the rest), you’re already on the right track to an accessible web, because semantic HTML is the foundation of everything accessible.