WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web accessibility questions

for

From: JP Jamous
Date: Mar 9, 2019 11:58AM


Michelle,

Since I was unable to read your whole e-mail due to its length, I am going to cover the buttons versus links and another 2 important factors to keep in mind. Those should hopefully help answer most of your questions.

This is a highly debatable concept between a button look versus a link look. What UX designers now do does not take in consideration A11Y for the most part. Also UX designers are highly visual that they tend to focus on making the visual distinction rather the programmatic one.

Once this gets to developers, agile forces developers to just code and who cares if the markup is a link or a button. As long as it looks the way it is in the UX design, that's what matters. User stories get done on time and the sprint is closed.

When it comes to someone like me who is blind and relies on JAWS versus my wife who is sighted, we start arguing. She tells me to click on the "transfer" button and JAWS is reading it as "Transfer" link. I almost lost my marriage and ended up in a divorce because of this type of implementation. *Smiles*

Keep in mind that I had full 20/20 vision for the first 12 years of my life. So I totally understand where my wife is coming from, when she states button. Yet, she has a hard time understanding why I am hearing it as a link. To save our marriage, we agreed to just call it "Transfer", because at the end of the day, the money is going into her bank account. LOL

So this issue is not covered by WCAG 2.0 or 2.1 and it is that way to ensure that WCAG does not restrict the design of a UI,, in my opinion. How you work this out with your UX Design team and Developers is the important part.

1. Since WCAG is always behind technology and was meant to be general in the sense that it does not impose strict restrictions on designers and developers, it is your job as a A11Y specialist to work with the designers and developers. For example, I always make sure I have a robust relationship with the business owners and UX Designers. I work with them closely using the logic of "give and take" to keep business requirements while ensure accessible UI. By the time I am done with them, the UI has 90% of A11Y defects eliminated. I then move to developers and review their markup. I suggest to them any modifications to ensure they do not use improper semantic. Once I am through with that phase, I know that the page has 1% or 0% defects. It is only my professional approach to keep up with an agile environment, while ensuring that both business requirements are addressed along with UX.
2. The other thing to keep in mind is that frameworks such as bootstrap do not always consider A11Y. You then have to find ways to work around those restrictions that frameworks impose on you. For example <i></i> is to load icons in bootstrap. Well, that gets selected by Voiceover on iOS devices. The blind user hears that tick sound that something got selected, but Voiceover does not state anything. What would you do then?
I have made it a rule that if developers want to use such a function, then they need to add aria-hide to it. For example, <I aria-hide="true"></i>. With that it hides the tag from screen readers.

With the badge that you were mentioning, you may want to consider the best approach to your users. For example, modify a bit the look of that badge container using CSS, or even use a <<img>> instead of the bootstrap tag. After all, you have to figure out the best solution for the best outcome of the UI. It is your job as an A11Y specialist.

Bottom line, there is no right answer to all of those questions. Awareness, education and networking are quite essential to work around those loose ends. Together as a team, you will be able to ensure that business owners, UX designers and developers are all on the same page with you. Once you learn those skills, you would realize how powerful your job is to ensure that the UI is accessible to the most amount of users out there.

So rather than thinking of yourself as a UX designer or developer, think of yourself as an advocate that uses diplomacy to achieve a proper end result. Use WCAG as the guidelines that you fall back on to ensure that your advocacy work follows a proper structure. If you just focus on interpreting WCAG guidelines as if they are the law of the web to apply upon your designers and developers, you will not achieve much success with those teams and you will face too many challenges and even rejection of your suggestions that will make it to the end user in an inaccessible UI.

I hope this helps you think of the larger picture and how to apply WCAG guidelines across the many roles in an agile environment. It is not an easy job, but the more you do it the easier it gets. There will be certain situations where you will find yourself facing a very challenging case. Always fall back to what I like to call the KIS method. You keep it simple to try to achieve the sweet spot.



--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------