Accessibility Questions on best practices for aria-describedby and form fields

天大地大妈咪最大 提交于 2020-06-27 06:26:46

问题


The following example is a typical form field for collecting a first name. I have an aria-describedby on the input referencing two different text-areas that help describe the inputs function.

  • The first aria-describedby reference is what I called "Hint" and is basically the placeholder attribute text on the input (aka the shadow text you see in the back of the text box). The “Hint” text area is a span with a class to visibly hide it but will still be read by screen readers.
  • The second aria-describedby reference is what I call "Help" and is the information bubble text (beside the label you can click the blue (i) icon to get help text).

My Dilemma! Using the screen reader JAWS and tabbing through my form field area it reads the information bubble. Then when I tab to the input it reads the label, placeholder text, Hint text which is the placeholder text I placed in a span, and finally the Help text which is the information bubble text again. I feel like the aria-describedby are not needed because the information was read twice!
On the other hand, if I take out the aria-describedby I may cause issues too from what I have read online. Some assistive technologies don't read placeholder text, so I should have it there to make sure the information is read. The information bubble is just kind of placed next to the label not part of it (so the association to the ‘control / label’ could be overlooked by accident).

(Sample of what was talked about above)

   <div class="form-group">
        <span class="required" aria-required="true"><i title="Required" class="fas fa-asterisk fa-cl" aria-hidden="true"></i><span class="sr-only">Required</span></span>
        <label for="Textbox3836">First Name</label>
        <span tabindex="0" role="button" class="text-info help-icon" data-balloon-pos="down" data-balloon-length="large" id="Textbox3836_Help_desc" aria-label="Tip: Please enter your legal first name."><i class="fas fa-info-circle fa-lg" aria-hidden="true"></i></span>
        <input class="form-control" type="text" id="Textbox3836" name="Textbox3836" maxlength="250" placeholder="Ex: Andrew" data-identifier="Text box" aria-describedby="Textbox3836_Hint_desc Textbox3836_Help_desc">
        <span class="sr-only" id="Textbox3836_Hint_desc">Example Andrew</span>
    </div>

Here is the information window showing

Keep in mind the type of users I need to support and the types of assistive-technology they will uses.

  • Blind (screen reader products like JAWS or NVDA)
  • Impaired vision (screen magnifying products like ZoomText or SuperNova)
  • Physical impairment (Voice navigation products like Dragon Natural Speak)

Additional Information: About the information bubble it used to be an icon tag with a title set on it but that is a mouse only feature and isn't friendly to assistive-technology.


回答1:


You aren't far away from where you need to be with this. Below are a few considerations / suggestions.

Accessible 'Tips'

Instead of using aria-describedby by on your tip, why not make the tip keyboard accessible. You may have considered screen readers but what about those who use the keyboard or other assistive technology without a screen reader. At present they cannot access your 'tip'.

The simplest fix (although not perfect) would be to show the tooltip on focus as well as hover and make the tip into a focusable item with tabindex="0". The downside of this is that your screen reader users would still need the aria-describedby

The better fix would be to make the tip itself accessible and also make it persistent / togglable.

So you would use a div or span with display:none for the content, next to the button within the DOM and then make it activate and hide on Enter key press.

Think of it like a mini-modal (so have a close button and make sure it can be closed with Escape key. Unlike a modal you do not have to trap focus, however you should move focus to the tooltip using tabindex="-1" and some JS and return focus to the button that opened it when it is closed).

This article about tooltips and 'toggletips' is a good reference point, 'toggletips' is the method I am suggesting as it fits the purpose of your 'i' button better.

Asterix for 'Required'

I noticed you added some screen reader text here, which is great. However you haven't considered people with cognitive disabilities. Stars are not as clear as writing "(required)".

By using " (required)" (written within the <label> after the name of the input, e.g. <label for="Textbox3836">First Name (required)</label>) instead of "*" you then remove the need for your "sr-only" text and the reliance on font-awesome fonts (which have their own accessibility problems...see the final heading 'Final Considerations').

Using aria-labelledby to expose placeholder text to screen readers that don't support it.

There is no right or wrong answer on this. Yes some screen readers do not expose this information and others do, no matter what you do you are going to give a less than optimal experience for some users.

I would stick with the way you have done it, better to have some users hear information twice than not at all.

However you could argue that because you have exposed the hint information correctly in point 1, the second bit of information is then not necessary so could be removed, leaving it in place as a placeholder for those screen readers that do read it.

What you could do is include the information within your 'tip' at the end "Tip: Please enter your legal first name. (e.g. Andrew)"

Going to the extreme here, not sure whether you should use "e.g." or "Ex:" for example, I will go do some research as I always use "e.g." but you made me think.

Final considerations

As I mentioned earlier, "font-awesome" and other icon fonts can make your application less accessible if the end user replaces fonts.

For example a user with Dyslexia may use a custom stylesheet to override all the fonts on your page. At this point your icons become 'missing font squares of doom' and lose all meaning.

Instead use an inline SVG, they are faster, more accessible, reduce the need for over 100kb of fonts slowing your initial page render down and allow you more control.

Finally on the image you show of your input the contrast between the input and the background may not meet contrast requirements (haven't checked) - the input (either the border or the background) should have a contrast ratio of 3:1 to the background of where it is on the page.


Also you may find this semi-related post interesting with regards to how I suggest to handle the title attribute on an image. It might help you put a pattern together for your 'tips' section.

What would I do?

I would keep it simple, design all these elements into the page in the first place.

It makes everything cleaner in your markup, is easier to maintain, provides hint information to everybody, saves the need for font-awesome and with a bit of fiddling can be made to look just as nice (my example is a bit rough).

See example:

.input-container label, .input-container span{
  display: block;
}
.input-container label{
   font-weight: bold;
   font-size: 1.2rem;
   cursor: pointer;
}
.input-container span{
   color: #555;
}
.input-container input{
   display: block;
   width: 94%;
   margin-top: 10px;
   padding: 2% 3%;
   border: 1px solid #666;
   border-radius: 5px;
}

.input-container {
   width: 75%;
   padding: 15px;
   background-color: #f8f9fa;
   border: 1px solid #333;
}
<div class="input-container">
  <label for="ID1">First Name (Required)</label>
  <span>Tip: Please enter your legal first name. For Example 'Andrew'</span>
  <input id="ID1" placeholder="Your First Name"/>
</div>


来源:https://stackoverflow.com/questions/60806969/accessibility-questions-on-best-practices-for-aria-describedby-and-form-fields

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!