This week I had a bunch of requests from clients surrounding VPATs and ACRs. This article will be a living article where I’ll post extra questions I receive as they come in.
Comments closedAccessibility, Artist, Music, Philosophy
Author: rhomexblak
When it comes to writing code that supports accessibility, there can be multiple ways to solve a problem. The industry has worked hard to standardize interactions so that component types function the same across environments. But, it avoids being dictatorial in how to remediate a given problem by only providing generic code samples.
Likewise, when we conduct accessibility audits, we will face user experiences that do not make sense to us. Nevertheless, the client is invested in these experiences. Perhaps the client has limited bandwidth to do remediation. The complete and proper resolution can be more than the client can get done in a reasonable amount of time. Yet, we want to help them achieve an accessible solution sooner.
In these cases it isn’t always appropriate to tell a client they need to completely change their code. Sometimes the solution is a small modification. Let’s examine a recent situation I encountered. A modification can fix the problem, even if the ideal remediation is a code change.
My client presented a website with some filters at the top of a table. The client initially coded the filters as multiple buttons per the design team’s layouts. Each button filtered the table in a different way, and only one filter can be used at a time. You can also have no filter applied. Upon examination, these buttons were properly constructed, but missed a state attribute and aren’t grouped.
I can justifiably tell the client to remove the buttons. They should replace them with radio button elements instead. Then, restyle them to look like a button grouping with one pressed. For no filters, we’d offer up a “Unfiltered” choice. And this will certainly fix things. In the long run, I want the client to follow this plan. It’s the most complete solution.
This change means the client needs to dig into their JavaScript. They must find the code related to the filters. Then, update it to respond to radio buttons instead of button elements. The client’s front end team will need to write new CSS and HTML. But remember they have limited resources, and we need them to fix things as soon as possible.
How do we help the client meet their goals?
There is another perfectly valid way to fix the problem. I can coach the client to add the aria role of “group” to the wrapping container. They should also add aria-pressed to the active filter button. This informs assistive technology that these items are related. It also fixes the state issue where we don’t know which filter is active. This solution takes roughly 10 minutes to fix, where the full remediation to proper radio buttons will take significantly longer.
The simpler recommendation may allow the client to fix more issues with the resources they have. Every step is a move towards better accessibility. Take the time needed with your clients to understand their current situation and needs before writing your recommendations. Don’t be afraid of offering up a “quick fix” for a client, as long as it actually fixes things.
Comments closed
When it comes to accessibility for digital products, we look to the W3C’s Web Content Accessibility Guidelines (WCAG) to point us in the right direction. WCAG carries with interaction guides to how users can expect a digital product to respond regardless of their method of interaction. This common language we use to make sure that a website, application, kiosk, mobile app won’t be confusing to new users. However, WCAG isn’t prescriptive in demanding things be done a specific way. And more importantly, just like accessibility isn’t a destination, neither is WCAG conformance. Its just the baseline we start from, we can go beyond it.
What does it mean to go beyond?
Keeping things generic for a moment, what does it really mean to go beyond a standard? This may not be clear of possible in all situations, but to go beyond a standard, we need to first achieve that standard, then add features that enhance the usability and user experience.
Let’s try an example
We’ll establish that this is an ecommerce site. During development, we add a link to the end of each product description. To meet the guidelines we’re working with we need to make sure it stands out from surrounding text. To make it standout, we underline it and use a different color. For this imaginary link, the color we choose has a 3:1 contrast with the surrounding text and 4.5:1 with our background. This meets the barest of guidelines laid out in WCAG. But we can do more than this.
We’ve already cleared WCAG 1.4.1 Use of Color as we have our link underlined. Next, let’s look at the text. Our link is in the middle of a paragraph describing a product by Acme MFG, inc. The link reads, “More information” immediately following the product description.
The Acme MFG Ultra Juicer 3000 is a state-of-the-art kitchen appliance designed for health enthusiasts and busy families alike. With its powerful 1000-watt motor and innovative cold-press technology, this juicer efficiently extracts maximum nutrients from fruits and vegetables. The Ultra Juicer 3000 features a wide chute that accommodates whole fruits, reducing prep time significantly. Its quiet operation and easy-clean components make it a convenient addition to any kitchen. The juicer comes with multiple speed settings, allowing users to customize their juicing experience . Acme MFG’s commitment to quality is evident in the juicer’s durable stainless steel construction and 5-year warranty. More Information.
Some of you are probably getting wound up by the name of the link, be patient, because the above link passes WCAG 2.4.4 as it has context before it. It is reasonable to assume the user knows this link will take them to more information on the juicer. However, if that link were brought up in a link list as most screen readers provide, it loses the context and reads, “More information” in a list of links that may or may not be unrelated. Most of would go back and revise the link to read, “More information on ACME Ultra Juicer 3000.” And this is great! It takes this particular issue and meets WCAG 2.4.9 AAA. But have we gone beyond WCAG?
A lot of times we provide controls to do something on the page. Most accessibility specialists will recommend that the control tells you what it does. Our link above will take you to the ACME website for details and service manuals.
WCAG doesn’t directly apply to this.
The industry as a whole agrees that if a link or button opens a new tab, window, or dialog that the user should be alerted that control will do just that. But WCAG doesn’t address this. We add icons (with alt text) or text saying “opens in new window”, “opens dialog”, or similar to inform the user what is going to happen. We do this to prevent surprises, confusion, and disorientation of the user.
Going Beyond WCAG means that you recognize that accessibility is the first step in a good user experience, but a good experience isn’t enough. Great products have great experiences, so combine your accessibility knowledge with usability and user experience. And if you are a designer, great accessibility is great user experience, don’t discount either.
Comments closed
I’m taking a break today from my normal work of auditing and coaching clients on how to make their digital properties more accessible to celebrate Global Accessibility Awareness Day. GAAD is a time when industry professionals, accessibility advocates, and disability defenders make a concerted effort to bring the conversation to the front.
Now this may sound like what I do every day, and it is. My company asks us to do volunteer work, giving back to the disabled communities around us. And you may say to yourself, “Doesn’t Nat already do that?” And yet again fine reader you would be correct. I spend a significant chunk of my free time serving on the board of directors for the Wisconsin Council of the Blind and Visually Impaired. I contribute to the W3C.
But I’m not walking away and making excuses. This year I reached out to VeDA and volunteered to help them with their accessibility. I’m currently working on the audit, but once that is done, I will also help them repair the code base.
Take some time today to do volunteer in making someone’s life better.
Comments closed
This probably isn’t the first time you’ve heard it. Somewhere along the line somebody asked you how well your site or application works for people that are blind. You probably mumbled something along, “They don’t use our stuff,” or maybe, “I don’t know, does it matter?” The short answer is, yes it matters. And you want to pay attention to why.
Accessibility isn’t Just the Blind
Accessible products and websites are often built with the blind in mind, however what it means to be truly accessible runs much deeper than that. Accessible by it’s very nature means that anyone, anywhere, with any tool of their choosing can use it. This means the disabled, which is not just the blind, but those with hearing, neuro-diversity, mobility, physical, and learning disabilities; and it means the abled that are compromised by other means.
Economics plays a huge part in accessibility. AOL still has 2 million people using dialup internet. This is an economic issue. ISPs have decided it isn’t beneficial enough to run faster lines to these areas or they are on fixed incomes and can’t afford the rising cost of internet access. Developing nations don’t have access to the funds to buy the latest and greatest technology, so they use products released years ago to get online.
As developers we all cheer when we hear that Microsoft is dropping all support for browsers below Internet Explorer 11 next week, but how does someone in an African country who can’t afford to upgrade from XP going to feel when we don’t support IE9? And what if that great new mobile application you created only works on iOS 9+ and Android 4.4.4? Many lower income folks in the developed and developing worlds have phones that are 2, 3, 4, or 5 years old and don’t support the latest things we can do with the web or mobile.
Building accessible products and sites means taking all this into account. It is using responsive web design to make sure your content is readable on all devices regardless of size. It is using solid HTML to make sure the content is parseable by a variety of technologies on the client side from browser, to apps, to refrigerators and TVs. It is using progressive enhancement to make certain that the product is usable even when the CSS or Javascript fail to load. It requires building products that while that may be single page applications running on Angular, React, or Ember continue to be useful applications when the CDN doesn’t connect or the connection is slow. It means setting a performance budget so that we aren’t trying to load 3 megabytes of data to run a blog. Knowing to reduce images, minify scripts, use CDNs to load things faster, and trying your darndest to limit any single page to something that will load in under 4 seconds and be usable.†
But Why?
Getting back to the disability side of things, recently the DOJ has taken to pushing through that public websites are liable to be accessible to the disabled. There is recent legislation that is forcing airlines to improve their websites. Netflix, Target, H&R Block, and eBay have all been sued by disabled people because their websites weren’t accessible.
You probably have a good idea what a lawsuit brought in federal court would cost your company even before remediation and damages are incurred. Why get sued when you can save money fixing the problems first?
I’m Here to Help
Your competitors haven’t solved this problem yet. Many are in the same boat as you and don’t know where to start.
With over decade of experience in front end development, user experience design, and accessible development I can get you ahead of the curve. Working together we can do a proper assessment of your website in all the major assistive technologies to make certain any deficits are found before you end up in court. With an active assessment done and a remediation plan in place you can resolve many legal actions before they get started.
Once you know where the problems lay, I can work with or train your team on how to resolve those issues bringing your site up to par with WCAG 2.0 AA standards. This is the standard level used by the Canadian, United Kingdom, Australian, and Japanese governments to write their web accessibility legislature. The European Union has used it to craft theirs; and the United States has similar legislation based on WCAG 2.0 AA facing it for a vote.
Contact me to set up a time to discuss your needs so we can set your product or site off as a differentiator in your industry because it is accessible.
† 4 seconds is a magic number that will cause people to think your app is slow. If your customer is using dialup, then a 500kb page will take 1 minute and 13 seconds to download. Sure 3 megabytes is instantaneous on your home cable connection or 4G smartphone, but in the developing world it could be a minute.
Comments closed
This weekend I had the pleasure of speaking at the inaugural edition of Open Source & Feelings. It was an amazing conference tackling some really hard topics. I received really great feedback from the audience on my “Designing with Empathy” talk and several asked for the transcript as they couldn’t take notes fast enough. So here is the talk broken out with what was on the slides as well as the script I tried to follow. The video is coming, and I will add that when available.
When I first pitched this talk, I was thinking it was about accessibility because that’s usually what I speak about. As I wrote it. And rewrote it. And rewrote it. It evolved into being something bigger, higher level, and more important than just accessibility. It became about thinking of others and building experiences that we can all be proud of.
Trigger Warning
Some slides contain content that may trigger motion sickness
#DZY
Some of my slides contain motion that could make you feel ill. I’ll give you a warning before they occur.
Empathetic design makes badass users.
Comments closed
More than once I have spoken about giving the user control over their experience. Too often we make assumptions about how things should work, but in the end those assumptions always forget someone. Providing a set of tools for the user to control the situation or experience allows us to have the most rich and dynamic experience we can build, but one that any user can get behind even if they can’t do all the fancy bells and whistles.
One such example is animation in social media. We love (I know I do) to post animated gifs, videos, vines, and cool new web animations in a place where our friends and colleagues can see. For me, many of these (especially videos and animations) will trigger a vertigo attack. The wrong kind of animation could cause someone with photo-sensitive epilepsy to have a seizure. I have a little faith left in humanity and hope no one posts these kinds of things with the intent to harm, but we can do better.
I’m not asking you to stop posting these. Instead I’m asking to give your followers control. If you come across a video full of violence, profanity, or sexual content while at work (or somewhere you would be embarrassed to get caught viewing it), you appreciate when that video has a NSFW (not safe for work) tag on it. We have learned what this means and now have the choice to view it or save it for when we are less likely to be embarrassed if caught.
We also have TW (trigger warning) for articles that contain descriptions of sexual assault, abuse, or suicide. We recognize that some people out there will be dramatically affected if they read these things, so we let them know up front it could happen. They can then choose to keep reading or not. They have the choice and the control.
So, I’m pushing for two new tags. One warns users that the content may cause dizziness, the other warns against possible seizure inducement.
#DZY
DZY, short for dizzy, but a clear concise item that takes up no more than 4 characters (if including the octothorpe – #). It communicates that the following content may cause some vertigo, motion sickness, or dizziness in some users. Putting this in a tweet with a link allows users like myself to decide if they want to click on it. The user has control. They can click through knowing they will see movement (knowing goes a big way in prevention), or if they are having a bad vertigo day (like I am right now) they can avoid it completely.
#SZR
SZR, short for seizure, is the same concept but for things that strobe and flash. Nothing should ever be created in a strobing or flashing manner that riggers epileptic attacks, but if you aren’t sure if it will, you can now warn your followers and users that something is coming that could.
Leave a Comment
Last week I got to be on a podcast. This week I appear on a screencast with Rachel Nabors talking about vestibular disorders in general and how animation may affect a user on your site.
If you don’t know who Rachel is, she is an amazing illustrator, cartoonist, speaker and animator using all those skills to shine a light on the web can be a better place with the right kinds and amounts of animation.
We had a lot of fun recording it, but I need to get a better microphone, sorry for the scratchiness that my beard brings. Also, we had a few problems trying to record it. Running Skype, Camtasia, Quicktime, and all the websites we looked at kept crashing our GPUs.
The screencast is on Youtube, and you should totally subscribe. She hasn’t done one in a while and it could be another while before we see another, so unlike the podcast episode I did, I’m embedding the video here.
Enjoy! Hit us up on Twitter with any questions you may think of.
Comments closed
Last fall I met the great hosts of CtrlClickCast at CSSDevConf and they were gracious enough to invite me on the show. I got together with Lea & Emily last week and recorded an episode on Accessibility. It was super fun! I hope to do more podcasts (but I need a better mic!).
The episode is now live! Go listen to it. Really, right now. I’ll wait. It’s about 50 minutes long and Emily and Lea have had the show nominated for the Net Awards recently, it’s a really great show.
Here is a direct link to the full transcript.
I’m not embedding the podcast here because I want you to go to iTunes or Stitcher and subscribe. And after you listen, give a review!
Comments closed
Last week I encountered a pseudo 3D animated gif from Doritos that autoplayed while viewing my Twitter feed. This gif was brightly colored, and its “3D” effect triggered a vestibular attack and migraine. As I looked more into the issue, it isn’t just Twitter who does this. It also happens in our Instagram, Vine, Facebook, and Snapchat feeds, just to name a few. Now some of you will tell me, “those channels are meant to work that way.” True, but what if due to advertising, or worse hacking, someone uploaded a gif worse than this Doritos one that autoplayed and triggered a photosensitive epileptic seizure? Who is responsible?
I would say whoever uploaded the gif is certainly responsible, but isn’t the platform as well? Do these really have to autoplay? When it comes to ads, is anyone checking to see if the ads meet certain standards? In radio and television, they don’t turn down ads because they don’t like the content, but if the ad promotes violence, cruelty, causes medical emergencies, or harm to the public, they will refuse to air it. I argue that those similar rules need to apply to the social networks we enjoy as a primary source of content.
I personally want an apology from Doritos for causing me pain. I know it wasn’t done on purpose, but that doesn’t mean it couldn’t have been avoided. Good marketers and user experience professionals need to know the audience and if their audience might have a medical condition that this type of ad would bother, then need to change that ad.
I’m also asking Twitter, Vine, Facebook, Instagram and all other social media platforms to put controls that prevent autoplaying of videos and gifs. The user needs to have control over their experience if movement may trigger physical pain.
And for those of you saying I shouldn’t use the Twitter web interface, why is it there if not to be used? Typically I use my phone, but as a consultant I am on many different machines in a week, some of which can’t have clients installed, and sometimes I’m in buildings where my phone won’t work for security reasons.
Comments closed