Inclusive Design 24 (ID24) is happening again on November 16, and I can hardly wait. If you’re not aware of what ID24 is, it’s twenty-four hours of free talks on accessibility and inclusive design. Each talk runs for about an hour, and the entire event lasts for twenty-four hours straight. I told myself I wasn’t going to stay up for twenty-four hours again at the end of the last event, but now that it’s happening again I’m seriously reconsidering that, because it’s so much fun and there’s so much stuff to learn and cool people to engage with using the #id24 hashtag on Twitter.
In anticipation of ID24 happening again, I thought I’d share my favorite web-related talks from past events. The one I’m sharing today is “Designing for Inclusion with Media Queries,” and it was given by Eric Bailey. Eric is a Boston-based user experience designer who helps create straightforward solutions that address a person’s practical, physical, cognitive, and emotional needs using accessible, performant, device-agnostic technology. You can find him on Twitter as @ericwbailey and you can read more about his work at ericwbailey.design.
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.
Recently, I was told by more than one person who had a private meeting with VFO salespeople at CSUN 2017 that the guys trying to sell JAWS are telling those who buy enterprise site licenses that “NVDA is just two guys working in a garage, if they’re hit by a bus, the whole thing disappears.”
NVDA: Now More Than Ever!
I’d like to talk a little bit about the “two-guys-in-a-garage” argument. Chris goes on to demonstrate why it’s completely false in NVDA’s case. But even if it were completely true, it’s still one of the most short-sighted arguments that can be used against FLOSS. “Two-Guys-In-A-Garage” is the argument you make when you have nothing else. You can’t prove that your functionality is better, so you try to argue in favor of scarcity.
We’re at the point where Jaws for Windows, (the so-called best-in-class screen reader), is aping NVDA, (its FLOSS rival), in order to stay relevant. This is especially evident when it comes to the web, where NVDA shines and where Jaws for Windows continues to lag behind. And unfortunately for VFO, (the parent company behind Jaws for Windows), the web their screen reader struggles with is the thing that’s eating the world. Everything is going web. It’s not just pages anymore, it’s applications now too. And Jaws for Windows can’t keep up with NVDA in this arena.
I, like a lot of other people in this community, was devastated by the news that Window Eyes is being discontinued. But NVaccess and the rest of the NVDA community are providing us with the freedom and choice that the big player believes they have the right to take away from us, and this is very heartening. So NVDA, you keep being you and doing what you do best, because when VFO crashes and burns, I want to be first in line to dance on its grave with a drink in both hands.
When WebAIM evaluates a client’s website for accessibility, we often spend more time evaluating and reporting on ARIA use than any other issue. Almost every report we write includes a section cautioning against ARIA abuse and outlining ARIA uses that need to be corrected or, most often, removed. Ironically, this is often followed by a list of issues that can only be addressed with ARIA.
This quote gets to the heart of my own love-hate relationship with Aria. As a screen reader user, I’ve seen abuses that make me want to strangle developers. I think the worst abuse I’ve ever come across, (and I’m sorry I can’t find it again to provide a demonstration of it), was one where role=”alert” was used to deliver advertisements and calls to action on a website. And it definitely did. “Alert! Buy our stuff! Alert! Download our e-book! Alert! sign up for our mailing list! Alert! Here’s this cool article you should read about whatever hot marketing tip! http://something.something/keyword! Alert! Here’s this other cool thing you should read!” Every few seconds. I have no idea whether the site’s developers or owners or marketers were specifically intending to advertise to screen reader users, or whether they were just trying to get past ad blockers, and I don’t care. All I know is, that site enraged me more than any comments section ever could, and I couldn’t close the window and file it under “Places You Never Go on the Internets Ever Again Under Any Circumstances” fast enough. WordPressers, do not ever do this. If you build sites for clients in any capacity, do not ever do this.
Admittedly, what I’ve recounted above is an extreme case. I’ve never come across anything like it again since. I’m recounting it though because what we as web professionals and hobbyists do on the web has a real impact on people, positive or negative. Whether that impact is positive or negative is solely dependent on us. We can make the web a place for everyone to enjoy and learn and be entertained and obtain things, or we can make it a place that people want to stay as far away from as possible. It’s up to us.
When websites and applications are badly designed, they create barriers that exclude people from using the web as it was intended. Poor accessibility creates a disabling environment where the design does not consider the wide variation in human ability and experience. In other words, disability is a conflict between someone’s functional capability and the world we have constructed. In this social view of disability, it is the product that creates the barrier, not the person , just as design is at fault when a site has poor usability.
Finally, a three hundred and sixty degree view on transcription.
BobWP, (otherwise known as Bob Dunn), has written down his thoughts on podcast transcription specifically, but I think they also apply to transcription in general. You should go read his post, because my thoughts spring from his.
The part of the post that struck me the most was the brief discussion of possible revenue loss. Not only is there a cost for the transcription itself, (which Bob has determined is the cost of doing business), but sponsors are also hesitant to cover transcription costs for fear of losing revenue from podcast listeners. And if we’re totally honest, businesses don’t sponsor podcasts for exposure, they do so for possible revenue from listeners. To be honest again, the reason non-hobby podcasts exist is to drive revenue to the businesses putting them on. If a podcast or podcast network can’t produce at least revenue, and ideally profit, then it goes away because it’s an unnecessary expense. For an illustration of this, see what happened to the Serotalk Podcast Network.
Podcasts specifically are very difficult to monetize in the first place, unless you have a metric ton of listeners. So I’m glad to see that, despite the failed crowd funding campaign Bob ran to get his podcast episodes transcribed, he’s chalking it up to the cost of business and going ahead with it anyway. While I’m glad Bob is doing the right thing, I think advocacy for podcast transcription specifically needs to take the cost/sponsorship part into account. Podcasts that are raking in enough to pay for expenses and make a profit have no excuse to leave it out. But for smaller podcasts, I think a pragmatic approach is going to be more productive than activism.
For accessibility advocates appearing on podcasts, offering to cover the transcription cost of at least that episode could be one way to handle transcription, and for podcast creators, reassuring sponsors that they will have an ad more appropriate to text content could also work. These are just ideas, but I think both of these could serve as possible solutions to the lack of transcription in the podcast realm.