Amanda Rush

(Placeholder, edit later) WordPress powers over a quarter of the web. With such a large market share comes a shared responsibility to create a web that everyone can use and enjoy, regardless of how they access it.

Read Accessible Death – Songs by Joe O’Connor

I’m putting together this play list for my wake and writing about my life while I am able. Time will come when I won’t have the strength. I want to make sure that my daughter Siobhan ( born with severe intellectual disabilities) understands what is happening and that she feels included in the process. I’ve used some songs she will recognize. In this way she’ll hopefully feel included.

I’ll update this post later once I can manage to get my thoughts together so that the words I’d like to say while Joe is still with us are in some kind of order instead of a jumbled mess mixed with grief and swearing.

I’ll try to do it quickly. Hopefully there’s enough time.

If you don’t know who Joe is, he’s one of the original gangsters of WordPress Accessibility.

Through this connection he is someone very dear to me.

Read NORMS OF COMPUTER TRESPASS by Orin S. Kerr (Columbia Law Review)

This Essay develops an approach to interpreting computer trespass laws, such as the Computer Fraud and Abuse Act, that ban unauthorized access to a computer. In the last decade, courts have divided sharply on what makes access unauthorized. Some courts have interpreted computer trespass laws broadly to prohibit trivial wrongs such as violating terms of use to a website. Other courts have limited the laws to harmful examples of hacking into a computer. Courts have struggled to interpret authorization because they lack an underlying theory of how to distinguish authorized from unauthorized access.
This Essay argues that authorization to access a computer is contingent on trespass norms—shared understandings of what kind of access invades another person’s private space. Judges are unsure of how to apply computer trespass laws because the Internet is young and its trespass norms are unsettled. In the interim period before norms emerge, courts should identify the best rules to apply as a matter of policy. Judicial decisions in the near term can help shape norms in the long term. The remainder of the Essay articulates an appropriate set of rules using the principle of authentication. Access is unauthorized when the computer owner requires authentication to access the computer and the access is not by the authenticated user or his agent. This principle can resolve the meaning of authorization before computer trespass norms settle and can influence the norms that eventually emerge.

Read Scraping A Public Website Doesn’t Violate the CFAA, Ninth Circuit (Mostly) Holds by Orin S. Kerr (Reason.com)

The Ninth Circuit Court of Appeals has handed down a groundbreaking decision today on the federal computer hacking law,  the Computer Fraud and Abuse Act (CFAA).  In HiQ Labs v. LinkedIn, the court held that scraping a public website is likely not a CFAA violation.
Under the new decision, violating the CFAA requires “circumvent[ing] a computer’s generally applicable rules regarding access permissions, such as username and password requirements,” that thus “demarcate[]” the information “as private using such an authorization system.”  If the data is available to the general public, the court says, it’s not an unauthorized access to view it—even when the computer owner has sent a cease-and-desist letter to the visitor telling them not to visit the website.
This is a major case that will be of interest to a lot of people and a lot of companies.  But it’s also pretty complicated and easy to misunderstand.   This post will go through it carefully, trying to explain what it says and what it doesn’t say.

This decision is critical to maintaining an open web, at least in the United States.
Read Why I Have a Website and You Should Too by Jamie TannaJamie Tanna

A persuasive look at the many reasons why you should have your own website, and some of the benefits it will bring you.

This post has a lot of takeaways for non-developers and even non-technical people. You don’t need to be a geek to have a website.

Personally, I think it’s vitally important, for example, to use a website to maintain a record of all the free accessibility testing you do as a person with disabilities. While I’d rather that the “f*ck you, pay me” approach be adopted instead of every organization and its brother jumping on mailing lists and social media asking for free work from persons with disabilities, maintaining a record of all the free work you do that can be used later to complete the experience section of your resume is the next best thing.

Bookmarked Under-Engineered Text Boxen by Adrian Roselli (Adrian Roselli)

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.

Glad to see I’m not the only one who uses “boxen” as plural for “boses”.
Read How To Big Up Your Theme With Options for Twenty Seventeen by Claire Brotherton (A Bright Clear Web)

Released mid-2016, the Twenty Seventeen theme is still incredibly popular, with over 1 million sites using it. One downside is that it comes with very limited customizations compared to other themes.

This plugin appears to be an excellent option if you’re using the Twenty-seventeen default theme and don’t have the funds to hire a developer or designer to do customization work.

It never occurred to me to package customizer options for a theme into a plugin. I’m not sure why because I do this for custom post types and other theme-specific code snippets all the time.

The customizer is relatively accessible at this point, so I’ve begun using it more and more on my own sites instead of just leaving all the fun for my clients.

And the idea of packaging customizer options in a custom functionality plugin is one I’m definitely stealing.

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.

Read A New Era for the Genesis Framework: Recapping the Biggest Changes and How to Work with Them by Carrie Dils (Carrie Dils)

It’s been roughly one year since WP Engine acquired StudioPress, the makers of the Genesis Framework. There’s been a lot of forward progress, but it may have left some people feeling unsure about how to work with Genesis or best take advantage of new features.

I’ve always loved the Genesis framework, and I still use it on client sites. While reading this post by Carrie, I began to think that those of us in the Indieweb community may quickly need to embrace blocks.

Yes, I know, that’s basically heresy, but I’m thinking this may need to happen sooner rather than later since Gutenberg development is pretty rapid, the accessibility issues are being fixed pretty quickly, and the end of 2021 will get here before we know it. Post kinds as blocks, for example, would probably be a lot easier to share across themes, as opposed to now, when themes either have to be forked and customized or created from scratch to explicitly support microformats 2.

Granted, you can have indieweb without post kinds, but post kinds is what enables people to truly own all of their content. And right now, there are only a few people doing the heavy lifting with regard to themes. That’s an untennable situation for a ton of reasons.

In order for this to change, it’s going to have to become easier for other designers and developers, (let alone users), to implement this stuff, and there are two ways that can happen. The first is WordPress as a project adopts all the indieweb building blocks. This would be the best solution, but I don’t see it happening anytime soon. The second way is us adopting blocks on the model of something like the Automic Blocks plugin or similar, at least for the post kinds/microformats 2 part.

I suppose there’s a third way, where WordPress adopts things like webmention and the other open standards, and blocks for post kinds is the compromise.

These are all just thoughts, but the Genesis framework has somewhere around 250,000 users, it’s backed by its owning hosting company, and it really does provide an easy way for users to build sites, with some accessibility included. And I think expecting users to do the heavy lifting for themes just isn’t sellable.

There’s a lot of promise contained in Gutenberg and the whole blocks concept, including the up-ending of what is the current raging dumpster fire which is the WordPress theme ecosystem, (with some notable exceptions for some themes). I’m thinking we should go with the flow as best we can.

This post is the result of a quick discussion on Twitter that I think should be saved for later bookmarking/reference. Also, my Twitter client has some weird focusing issues which means the first part of the reply was sent to the wrong person. (Sorry about that Adrian). Lastly, Twitter seriously broke the thread so if you try to search for related posts you’re missing half of it.

Wendy Delfosse asks on Twitter:

Best places to start for learning to use WordPress with visual impairment? A user wants to know how to pick a great theme since he won’t be able to verify the design himself. Any tips greatly appreciated.

(Source).

More specifically, the user Wendy is asking on behalf of is looking for help with making sure their site looks good with background images, fonts, ETC. I responded in multiple replies with several tips based on my experience. Here are those tips.

Picking a great theme is very much dependent on what you consider great, including visually. Also, in the case of visually impaired, blind specifically, whether you have visual elements like images, for example, to help make a theme look like the demmo, except with your content/site.

So, to start with, does this user have a concept of what they’re looking for visually in a site? If not, I’d say start with an accessibility ready theme and then, once you’ve figured out branding/colors/images ETC., go from there.

Also keep in mind that no out-of-box theme will have everything you want. So make a list of things that are essential in a theme, then nice-to-haves, and then, once ready to grow, decide on budget for hiring out the visual work of site building/design.

Find a sighted person you can trust. Looks good is also unfortunately one of those things that to a large extent is in the eye of the beholder. Knowing what you want from a site in terms of who the audience is for the site is also helpful in this, because it helps narrow down the “looks good” part.

If it’s something like a personal site though, I’d go with picking an accessibility ready theme, and then, after that, don’t worry so much about how it looks to others except for basic contrast issues, which accessibility ready themes will cover adequately. In short, if it’s a personal site, just be yourself.

One last thing. When picking a sighted person to trust with this stuff, stick with one person. Be careful about second opinions as sighted people who are not designers/familiar with design principles/accessibility will give you widely varrying and often conflicting results. It’s kind of the same thing as asking a random sighted person how your clothing looks.

Off the top of my head, I think this covers the basics from this perspective. But, if there’s something I haven’t thought of, feel free to leave it in the comments, and I’ll update this post accordingly.