NZ questions and answers

← Index page

Question 1:

1. Does duplicate ids confuse the screen readers? does all elements need ids?

Answer

All HTML markup should be well formed and valid as defined by the W3C Markup Validation Service.

In an HTML page, all ID values must be unique in order for the document to pass validation.

In specific instances, duplicate ID values could cause issues for screen readers. A short list of examples where this could present issues include:

Dummy link after

Question 2:

Inputs like DOB (3 fields) have only one label. is the best accessibility practice to still have one label per input on those scenario, assuming they are off-screen?

Answer

Date of birth

Dummy link after

Question 3:

Links with JavaScript onclick to open dialogs/popup that are not navigating to a different page are acceptable?

Answer

As was mentioned by one of your team:

For this reason, the trigger for modals should be the BUTTON element.

Dummy link after

Question 4:

Is there any application/site/script we can use to identify how many accessibility issues we have in our portal just to make sure we are not accidentally increasing the number of problems as we progress with the changes?

Answer

WAVE

Dummy link after

Question 5:

Testing accessibility changes. How do we do that?

Answer

Tag me in all Jira tickets.

Dummy link after

Question 6:

We should make sure that every input field has a label (visible or hidden) that accurately describes the field (FOR). About hidden labels it was suggested in the last meeting we can set the fields outside the visible area including "absolute" position. Setting "absolute" position will remove the label from the DOM position where is placed, will the screen reader be able to "link" the input with the label even though its not in the DOM as a normal label?

Answer

In very specific circumstances, it is allowable to hide the LABEL element off-screen, but only when the purpose of the form control is clear and obvious to sighted users.

Hiding the LABEL off-screen is acceptable as long as it is absolutely positioned, and does not use display: none, as this will remove the element from the accessibility tree.

.sr-only {
  position: absolute !important;
  overflow: hidden !important;
  clip: rect(1px, 1px, 1px, 1px) !important;
  width: 1px !important;
  height: 1px !important;
  border: 0 !important;
  margin: -1px !important;
  padding: 0 !important;
  white-space: nowrap !important;

  -webkit-clip-path: inset(50%) !important;
          clip-path: inset(50%) !important;
}
<form action="#">
  <div class="form-container">
    <label for="name" class="sr-only">Name</label>
    <input id="name" type="text">
  </div>
</form>

Dummy link after

Question 7:

Should a input label and the input placeholder have ALWAYS the same value?

Answer

The placeholder attribute should be AVOIDED COMPLETELY as it presents a range of accessibility issues.

  1. Colour contrast - especially for users who set their controls to high.
  2. Congnitive impaired and users who are not tech savy - the placeholder information is wiped as soon as the user begins typing.
  3. Screen reader users - the placeholder is often announced AS WELL AS any label, which means duplicate information is presented to users.

You can see this in this test case:

The word "Fox" should not be announced to users at all, unless there is no label or title present. Instead, the placeholder is announced as well as the label and title if present.

Dummy link after

Question 8:

What would be the best approach to "link" a label with FOR attribute to the radio buttons for the example in the image in the notes. have 1 invisible label for each of the radio options? and add the "Adjust your policy excess" for attribute relating to the fieldset id?

Answer

This should be standard fieldset/legend markup. Note that the paragraph can be associated with the first input so that it is announced when the radio recieves focus.

Adjust your policy excess

The excess is the amount you will need to pay if you make a claim.

← Index page