Skip to content

Nat Tarnoff Posts

Ticketing Challenges: Finding Wheelchair Accessible Concert Seats

I love concerts. People performing live music is one of my greatest pleasures. Music is critical to my soul and is beyond crucial for keeping up my mental health.

My wife is less thrilled with concerts, but is always up for a fun time with the right people. Weird Al announced a tour with Puddles Pity Party. Two of our favorite artists. One of the stops is our home town just after our anniversary. One of our closest friends is also a fan and knows Puddles. Off I went looking for tickets!

Checking out the tickets I saw that Ticketmaster and StubHub were selling them. I know that resellers like StubHub tack on additional costs and fees. I do my normal thing and head directly to Ticketmaster instead.

My wife has POTS, so when we go out she is in a wheelchair. I have a vestibular disorder that makes standing for long periods impossible. It is made worse with loud environments and big crowds (Sounds like I shouldn’t go to concerts, huh?). So we can only go to shows that have seating & wheelchair accommodations.

The location they are playing at is mostly general admission to stand on the field. It’s a stadium, so there is some seating. Ticketmaster showed only 1 wheelchair accessible ticket. Most of the seated areas were marked “sold out” a day after release. I decided to check StubHub for those “sold out” areas.

StubHub showed there are tickets in areas where Ticketmaster said tickets were sold out and I’m thinking, “Options!” StubHub does not provide a way to filter for disabled seating!

Previous Outings

We went to see Marc Maron last year. I opted to buy, from TicketMaster, an “Accessible seat” on an aisle. Upon arriving to the facility, the accessible seat was a regular seat. No where in the purchase process did it say it wasn’t wheelchair compatible.

The onsite TicketMaster people helped move us to the ONE wheelchair seat as it wasn’t sold. There was only space for one chair and one companion. And of course another wheelchair user showed up and they stuffed them in with us.

I learned from this that even if TicketMaster says there is accessible seating, it may not be wheelchair friendly. And the only way to actually buy accessible tickets is to call the venue.

We aren’t going to see Weird Al or Puddles. The one “accessible” seat won’t work for a wheelchair user.

Comments closed

Improving Web Accessibility: Quick Solutions

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

Going Beyond WCAG

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

GAAD 2024

Selfie of Nat with the VeDA website behind him.

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

You Need Accessibility Testing

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

Designing with Empathy

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

Granting the User Control

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

Infinite Canvas 6 With Rachel Nabors

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.

Rachel Nabors

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

I’m on CtrlClickCast Podcast Episode 49

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