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
--------------------


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Michelle DeYoung via WebAIM-Forum
Sent: Saturday, March 9, 2019 11:17 AM
To: <EMAIL REMOVED> ; Michelle DeYoung < <EMAIL REMOVED> >
Cc: Michelle DeYoung < <EMAIL REMOVED> >
Subject: [WebAIM] Web accessibility questions

Hello!
I am not sure where or how to post my questions to the forum. Could you help?
Here are my questions:
Links in text should not rely on color alone to help identify them as link. How does this apply to links that are designed to look like buttons?The way things are designed anymore does no allow for links to always look like links and buttons to always look like buttons.Note: Buttons contain action text where links do not always do the same. Sometimes designers make "Buy Now" or "Learn more" appear as buttons when they are links to another page in the site.

An example would be a Submit button that looks like a button, and next to it is a Cancel button that looks like a link. The Cancel button is made to look like a link for a better UX so it is less likely to get accidentally selected or mistaken for a Submit button. If the Cancel looks like a button too, usually the designer will downplay the color, thus making the button look inactive or of the like.

In the example image below, the text "button" is surrounded with a border defining it as a button. Next to it is button text that is not surrounded by a border and does not provide a another means to differentiate the text as something that is possible selectable.


Understanding Success Criterion 1.4.11: Non-text Contrast

|
|
|
|
|
|

|

|
|
|
|
Understanding Success Criterion 1.4.11: Non-text Contrast |

|

|





Another example would be when designers have two links right next to each other, but one needs to be set off as being more important than the other. Designers sometimes choose to make one of them look like a button.

And what about Badges (Ii.e."Success", "New", "Warning"). Badges tend to look just like buttons, but are not always selectable, and do not always display action text. Badges can also be links that look like buttons. What is the recommendation for elements like linked Badges that look like buttons? How should they be set off to appear different from Badges that are not selectable?

See example Badges on the Bootstrap page.
https://getbootstrap.com/docs/4.0/components/badge/
Ideally links should look like links and buttons should look like buttons as this will help everyone. In the case of Badges that look like buttons, but can also be links, what is the recommendation?
Many times a slight or strong hover color can be applied for button elements or links, but there is no requirement for on-hover color or strength.

Why should links in content need to be set off (i.e. bold, underlined) so they are identifiable as links, but not buttons, or buttons that look like links, or linked badges? Does this only apply to links that are in a sentence or paragraph?----------------------------------

Different question: Zooming in on a page to 200% with [CTRL] [+] Ex:I have a text on a page that is larger than other text on the page, like a Blockquote. I commence zooming in on the page to 200% with [CTRL] [+].
As I zoom the Blockquote text increases in size along with the rest of the page.
But, when I get to 200%, suddenly the Blockquote text is smaller; say like it was at 150% and not larger like it was at 170%.

Does having mobile breakpoints set impact how a page is displayed or content is sized when zooming in on page content from a Desktop display?

If the the designer and developer decided the Blockquote is fine at 200% on desktop, but is way too large on a mobile display, how should that be handled?

Does zooming in on a desktop viewport engage the media media queries set for Mobile or are they or can they be handled independently of each other?
If they cannot be handled independently, how does this impact the following success criterion?
Success Criterion 1.4.4 Resize text (Level AA): Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
Understanding Success Criterion 1.4.4: Resize text

|
|
|
|
Understanding Success Criterion 1.4.4: Resize text |

|

|


Success Criterion 1.4.10 Reflow (Level AA): Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
Understanding Success Criterion 1.4.10: Reflow

|
|
|
|
|
|

|

|
|
|
|
Understanding Success Criterion 1.4.10: Reflow |

|

|



Thanks,Michelle DeYoung