E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 6 (In chronological order)

From: Michelle DeYoung
Date: Sat, Mar 09 2019 10:16AM
Subject: Web accessibility questions
No previous message | Next message →

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

From: JP Jamous
Date: Sat, Mar 09 2019 11:58AM
Subject: Re: Web accessibility questions
← Previous message | Next message →

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

From: Patrick H. Lauke
Date: Sat, Mar 09 2019 12:26PM
Subject: Re: Web accessibility questions
← Previous message | Next message →

On 09/03/2019 18:58, JP Jamous wrote:
[...]
> 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*

Pro tip: most non-AT users don't understand nor care about the
difference between a button or a link. Especially if they also use
native applications, where there's no such tangible distinction anyway.
The important thing is that if something behaves as a link, it should be
coded as a link, and if something behaves as a button, it should use a
<button> (or relevant <input>) element. How it's then styled is mostly
irrelevant to regular users, and it's quite common for prominent links
to be styled as pills/buttons/etc. It's not an unusual visual
presentation. For communication purposes, it's either easiest to just
refer to things as "controls" in general (which covers both), or...to
just have a bit of understanding that button and link are likely to be
used interchangeably by non-AT users. No need to call a divorce lawyer
over hairsplitting ;)

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jonathan Cohn
Date: Sun, Mar 10 2019 1:15PM
Subject: Re: Web accessibility questions
← Previous message | Next message →

Patrick says:
> an unusual visual presentation. For communication purposes, it's either easiest to just refer to things as "controls" in general (which covers both), or...to just have a bit of understanding that button and link are likely to be used interchangeably by non-AT users. P
> — The only problem with this is that most screen readers do distinguish between buttons, links, and onClick controls. If you ask me to find the "transfer" button I will bring up a list of buttons and type "T" to hopefully jump to "transfer". Also, buttons are considered form elements and links are not.

Jonathan Cohn

From: Patrick H. Lauke
Date: Sun, Mar 10 2019 5:28PM
Subject: Re: Web accessibility questions
← Previous message | Next message →

On 10/03/2019 19:15, Jonathan Cohn wrote:
> Patrick says:
>> an unusual visual presentation. For communication purposes, it's either easiest to just refer to things as "controls" in general (which covers both), or...to just have a bit of understanding that button and link are likely to be used interchangeably by non-AT users. P
>> — The only problem with this is that most screen readers do distinguish between buttons, links, and onClick controls. If you ask me to find the "transfer" button I will bring up a list of buttons and type "T" to hopefully jump to "transfer". Also, buttons are considered form elements and links are not.

Presumably though, once you can't find it in the list of buttons, you
then look for it in the list of links, or using a more general kind
search in general across the page? Similarly, there are many visual
designs that use "tab interfaces" that are really just links, and
similar "it looks a bit like this thing, but it's actually another
thing". You're going to get on very thin ice with "you should never do
this" type approaches.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Mallory
Date: Fri, Mar 15 2019 4:47PM
Subject: Re: Web accessibility questions
← Previous message | No next message

>Does zooming in on a desktop viewport engage the media media queries set for Mobile

Yes, generally. If the desktop browser supports zooming and supports CSS media queries (all the major ones seem to), then developers building a "mobile-responsive" page can, if they do it right, meet both the Resize Text SC and the newer Reflow (400% @1280px width) SC.

cheers,
_mallory