Well, we’ve discovered the problem: basic working-ness is seen as a feature and basic working-ness not being there is not seen as a bug.
Now, how do we fix this?
Someone I know who’s worked in the accessibility field since like forever over in Canada suggested that a school system teaching coding should have accessibility as a basic part of that curriculum. He was told “that’s pork-barreling curriculae” (pork-barreling is adding something to a law in order to (usually financially) benefit the lawmaker-- this person I know works in accessibility).
Teaching people how not to make broken things… seen as just a financial move.
The web will remain broken until we figure out how to teach basic-workingness with every web tutorial, book, course, etc. Broken software needs to be called out for what it is-- broken!
I throw out the idea that publishers, including SitePoint, should have article and code editors include basic-workingness as part of the editing process.
In cases where a section of basic-workingness might really be a whole other article, tutorial or how-to, the article should mention this in an obvious place, and link to the other article if available.
I love when Poes rages though this is a very mild rage, but her gripe is ridiculously valid. Accessibility is the black sheep of the industry - always ignored unless someone drags the issue back under the light. Just think about all the crap that’s been done because it was flashy and someone went “ooh, look what we can do”
Images instead of text
Flash for banners or fancy text.
Using javascript to add content/AJAX that could be gotten other ways.
All of these have been done just to make something flashier, and usually with no concrete benefit to the end user, and often at the expense of a portion of their customer base. The first two have luckily gone the way of the dodo bird and much better approaches have been found to accomplish the same thing. But #3 is still alive and kicking, and it causes all kinds of havoc, not only to those who have accessibility/disability issues, but at the expense of those whose connections aren’t the best. Mobile data plans just haven’t kept up with the increase of the bloat (unless you can afford $180 bucks a month for unlimited data - I can’t), and there are STILL portions of the US (not to mention the world) who don’t have access to high speed internet, And modern tools just make it worse, not better. How much bloat are in some of these frameworks. Granted, some have gone back through and re-engineered to remove bloat, but it’s still not there.
And to get back on topic (sorry, but this issue bothers me), but she’s right about this specific article - it’s incomplete, and the author just doesn’t seem to get that. He even admits that it should be considered, but it’s not - his out of scope just proves her point as there should be an emphasis on ensuring that “basic rights” or “minimum standards” are met before articles are published. Just goes to show you how badly the issue is ignored.
A good example of this would be the forum software we are using now. One of our team members (I’ll let the team member out themselves if they so choose) had a fight on their hands to get the keyboard access working. The developers didn’t recognize that as an accessibility issue (in fact, they considered it a “power user” issue, and not a critical one). If this team member didn’t fight that - and he/she fought with them LONG and HARD, I don’t think it’d be in the software now - in fact, another SPF member took it upon themselves to work it out, and I think ended up shaming them by doing it separately, which spurred a greater effort on their part. Without the efforts of these two individuals - then this forum software would be nearly unusable as a keyboard forum, which we have a decent number of keyboard heavy users for.
These concepts should NOT be ignored and should be one of the first considerations before the sparkles are added…
When the author says that something like this is ‘out-of-scope’, it reflects a way of developing that people need to move away from - build the basic application first, then add these ‘extra features’ later, such as accessibility requirements and security requirements.
The whole development world needs to start realizing that accessibility requirements and security requirements ARE part of the basic application, should be present right from the beginning and not added on as an after-thought to make the application ‘compliant’.
I have been guilty of that myself, because there is so much to remember and think about, but I am trying to change my workflow and build all of these necessary things into the main process.
This reminds me very much of the one-time prevalent attitude in certain manufacturing circle that used to think you could somehow introduce ‘quality’ by inspecting things as they went out the factory door. If quality wasn’t there to start with, inspecting it wasn’t magically going to make it appear right at the very end.
Quality is something that has to be embedded from the process from beginning to end, starting with user research, requirements, design, development, productionisation, deployment, and yes support (anyone ever heard of ‘design for support’). Whether it’s an aircraft or a small business CMS, they’re all amenable to the same basic steps towards putting a product out there. Build accessibility considerations into the process from the very start - you’ll end up with a better user experience all round. Heck, some of them might even begin to believe you care…
When I submitted many of the PRs for accessibility into Discourse’s core, it wasn’t from nothing, they had some support there, but it was very minimal and was a contribution from another member who had since moved on to other things. Was it still after the fact, yeah, it was, but we’ve made a lot of changes that were design changes and very specific to help those who use accessibility devices.
However, the issue many have today is proving the cost for putting in that effort is good for the company and the product. It is hard to do that with accessibility, very hard. As wrong as that is, as a developer, I struggle to find applicable arguments when presented with numbers showing 99% of our users don’t care/don’t need it (again, not justifying it, just elaborating on the point of view we devs have).
In fact, most of the time, it isn’t my call at all (as a developer). I can bring it up, but unless the business is willing to spend additional time and money to redo the requirements, wireframes, user workflow mockups, etc. then my hands are tied. Sometimes I win out, because, Mobile! Mobile requires an incredibly different thought process to a user experience and I’ve used it to make gains in accessibility too primarily because the original write up provided a horrible experience to Mobile users and I provided a mockup that worked for both mobile and accessibility.
Did I cover every aspect of accessibility in those mockups? Probably not, as I’m no where near an expert in it nor would I call myself a well informed person in it. I just know enough to ease pain points and hopefully that does more good than not.
So yes, I fully understand out-of-scope. I’ve given many of those responses myself. Because given the time and schedule I have, I can’t possibly add things that are not going to be QA’d or are going to be QA’d in a way that will fail once I alter how it is presented.
I think with a slightly different approach, you probably could convince the author to write a follow up detailing how accessibility may play into the techniques he utilized in his article. It could have been a great follow up article (still could be).
It’s the missing basics that irk me, but I see your point.
Ooohh, I just had an idea…
@Stomme_poes… think you could whip up a “basic rights” checklist that need to be considered? Or point us in the right direction where a definitive list could be found? I know the basics (or at least what I consider the basics), but I think everyone would be interested in a more definitive checklist.
Edit
After reading @chrisofarabia’s post I think the above list is more of a finish.
This reminds me very much of the one-time prevalent attitude in certain manufacturing circle that used to think you could somehow introduce ‘quality’ by inspecting things as they went out the factory door. If quality wasn’t there to start with, inspecting it wasn’t magically going to make it appear right at the very end.
++ to the WebAIM checklists, they’re fairly easy for people to get started with.
The known disadvantage of checklists is what those of you in the US see with Section 508-- it becomes a checklist to be checked off, meaning you can end up with something that technically addresses something in the specs but isn’t actually usable by real humans.
As for accessible-y stuff with JS, Heydon’s written a book called Apps for All: coding accessible web apps which shows a lot of these things people tend to need to build and how they would do them. There’s also untold number of articles on AListApart, webAIM, usertesting.com, Filament Group blog, Paciello Group blog etc etc on these-- SitePoint too (I’ve gone back to Léonie Watson’s SVG article a few times recently) – it’s just that often these are posted separately from articles about somewhat-introductory matter like Drag and Drop (same issue as this article), Web Components, stuff with Angular or Shadow DOM or React where accessibility often needs wholly new ways of being tackled, that don’t have it.
Instead of articles about accessibility, I think it’s a far better thing to just have accessibility be part of example codes-- just like the Javascript Anthology book does. Best Javascript book I’ve bought, and that was partially why-- every new bit of code, if there was some minor accessibility concern, either code for it was shown and just part of the example, or it was mentioned and maybe another resource was pointed to.
And like I said, sometimes the topic getting accessible is a whole thing in itself, like the HTML5 Drag and Drop article wouldn’t have been as concise if it also basically included everything in Brothercake’s article-- so instead, in those cases, it needs to be mentioned, prominently, and then a URL to the other article would suffice. With these new widgets, sometimes stuff (browsers, AT, specs) are still maturing so it ends up currently being a lot of hand-work, meaning possibly wholly-separate articles on these techniques make more sense, but other times, it’s maybe another line of code here or using a different element there is all that’s needed, with explanation (“we’re using a button element here instead of a div or a span because it comes automatically with the built-in behaviours we’d rather not code ourselves, such as being triggered by both enter and spacebar, being naturally focusable, and having a disabled state we can call”).
Also, is this a typo from the article? for(var i = 0; i & selectedItems.length; i++) {
Is he really checking if i and the arraylength exist? That doesn’t make sense. Or is it just a type of check I haven’t seen before? He does it twice. I read it as “check if i, then also always check if array has length.”
Edit: I guess you did hit the sentiment right on the head, Mitt. But I don’t know if it’s people grudgingly hacking around poor choices so much. Maybe it is, but usually people are saying to use another element rather than hacks…
That’s an example (used to be a common one, looks like Bootstrap’s got people using the right element more nowadays) of the developer not choosing the right element in the first place:
What does the element do? Why does it exist?
Users click it to Do Stuff on a page. That’s a different reason for existing than Showing A Picture (image, background image, svg…).
So that naturally presents a button: links navigate elsewhere, inputs send information somewhere, neither of those use cases work, so button it is.
Plus they get to have images inside them, the OS → browser adds in all the BS for us, the alt can be the button’s accessible name (though visible names next to hamburgers work better for way more people) and now we can be lazy, sit back and drink scotch. Yay.
Accessibility, in some cases, really is work. But this one counts as that low-hanging fruit stuff, the stuff I want developers to do without thinking since it’s such a Pareto distribution it’s not even funny. And that takes us back to articles, tutorials, books, etc. having this stuff just in there from the beginning. Showing someone how to turn an img element into a button can be useful for those weird far-out use cases, but then the developer has made some choice and must then be willing to pay for that choice by hacking around their not-well-chosen element. So it’s good to know what all needs to be done there too, but it’s more ideal if the developer doesn’t even need to do it.
& is the bitwise and operator - each bit in i gets compared to the corresponding bit in selectedItems.length and if both are 1 then the result is 1. If any bit in the result is 1 then the test is true.
Not sure why anyone would be doing that though – even if that was a typo for the && operator doesn’t make sense.
Works for both mousers and tabbers without piling hack upon hack.
As for the lowly button tag. For a long time I thought of it as being an alternative to a form input type=“button” and was pleased when I discovered it could reside outside of a form.
Maybe a part of the problem is “too many tools in the toolbox” or maybe it’s human nature to stick with something once the initial “investment” has been made and a reluctance to change course, choosing to “patch” instead of fixing.
In any case I agree it would be better if accessibility (and security) were taught from the start. A lot of problems would be avoided that way.
It seems to me there are ultimately only two ways to get accessibility to be taken seriously cross the Web. You either have to convince site owners and developers that it’s their interests to do so (e.g. financially), or legislate for it.
Think of all the public buildings with wheelchair ramps, disabled toilets, fire escapes and so on. I’d wager that few if any of those features would exist without laws. The tycoons funding building projects don’t care in the least about the people in those buildings. It’s all about making money. No laws, no accessibility/safety features. (That’s all too apparent where the laws are less strict or non-existent.)
So there are laws that apply to things like gov’t websites, and some other site owners have been fined for not providing an accessible site. But I doubt there’s much that can be done about “personal” sites, just as most private homes rarely have extra ramps etc. for accessibility. Appealing to devs en masse to do better is just as vain as encouraging builders to build better houses out of the goodness of their hearts. (I can see them reacting to that one over a cigarette.)
I certainly agree, though, that articles, books etc. should deal with accessibility as a matter of course, to make it seem as normal as possible and keep it front of mind.
