A11y keyboard focus control in the Input example

[DaveBest99]

Bug, feature request, or proposal:

Bug:
Using JAWS with browsers Firefox, Chrome, and IE11, reveals focus issues most likely due to disassociated "label" and "input" elements. Note, the "input" element has a blank "aria-describedby= " attribute.

What is the expected behavior?

Text labels must be associated with the Form element, and default text should be spoken.

What is the current behavior?

Currently, some Edit Input fields have no text labels shown on the braille display, and there is no error detection.

What are the steps to reproduce?

See below.

What is the use-case or motivation for changing an existing behavior?

To allow for WCAG standards.

Which versions of Angular, Material, OS, browsers are affected?

Latest.

Is there anything else we should know?

The screen reader user experience is as follows:

1. Press Tab key into the component.
   JAWS focus moves past the "Company" disabled Edit filed and to the first focusable element.
   JAWS says "First name edit" and braille display shows "First name ed".
   User can type multiple words in this Edit field without getting an error message.

2. Press Tab key to the next element.
   JAWS says "Long Last Name That Will Be Truncated edit", and the braille display shows "Long Last Name That Will Be Truncated ed".
   The user can type multiple words in this field.
   Note, when using Firefox, pressing Tab key forward will move focus to this field once, but pressing Shift+Tab key back through the input elements will display this Edit field twice if the Edit field is blank.

3. Press Tab key again.
   JAWS says "Address edit" (does not announce the input text), but the braille display only shows the input text and not the text label "1600 Amphitheatre Pkwy".
   JAWS does announce "contains text" if the input field has text.
   If the input Edit field is blank, then the braille display is blank (no text label appears).
   Note, when using IE11, the default Edit filed text "1600 Amphitheatre Pkwy" does not appear on the braille display (it is blank until the user types something), thus the user never sees the default text.

4. Press Tab key again.
   JAWS says "Address 2 edit", and the braille display is blank (no Edit field text "Address 2" label appears).

5. Press Tab key again.
   JAWS says "City edit", and the braille display shows "City ed".
   As expected.

6. Press Tab key again.
   JAWS says "State edit", and the braille display shows "State ed".
   As expected.

7. Press Tab key again.
   JAWS says "Postal Code edit 94043 5 / 5", and the braille display shows "Postal Code ed 94043 5 / 5".
   If the user deletes the default Edit field text, presses Tab key away and then Shift+Tab key back, JAWS says "Postal Code edit 0 / 5", which is also shown on the braille display.
   If the user types characters into the Edit field "abc", then JAWS will say and display "Postal Code edit abc 3 / 5" (no error message announced).
   Note, the number of characters in the Edit filed does not get updated unless the user moves focus away from the Edit field and then back again (it may not be clear to the user as to the purpose of these numbers).
   Note, when using IE11 and unlike the Address field, the default text "94043" is announced and displayed by JAWS.

[mmalerba]

This issue covers a number of things:

1. Blank aria-describedby - created fix(input): fix blank aria-describedby #3713 to fix
2. Duplication of tab stops in Firefox - unable to reproduce
3. Textarea text not read by screen reader - seems to be how JAWS handles textareas, saw same behavior w/ native one
4. Textarea initially blank in IE - This is caused by a core bug (Textarea element in form when binding model has initial state as dirty in IE angular#14440), but we should update the example to work around it until its fixed.
5. Various a11y issues with the examples themselves

Since 1-4 have some resolution or another issue tracking them, I will re-purpose this issue for tracking 5

[DaveBest99]

Item 2. This appears to be an intermittent issue, as I cannot reproduce it consistently. Can be ignored. Item 3. While placeholder text provides important guidance for many users, placeholder text can be problematic for assistive technology users. Placeholder text is not broadly supported across assistive technologies and not displayed in older web browsers. Can try using a different method for displaying data, or try using the aria-labelledby attribute. input-demo.html <md-input-container class="demo-full-width"> <textarea mdInput placeholder="Address">1600 Amphitheatre Pkway</textarea> </md-input-container> Sample using aria-labelledby: <span> <input type="text" name="expire" id="expire" aria-labelledby="expLabel expDesc"> <span id="expDesc" tabindex="-1">MM/YYYY</span> </span> For more information see: Placeholder Research - Low Vision Accessibility Task Force https://www.w3.org/WAI/GL/low-vision-a11y-tf/wiki/Placeholder_Research David From: mmalerba [mailto:notifications@github.com] Sent: March 21, 2017 05:33 PM To: angular/material2 Cc: David Best; Author Subject: Re: [angular/material2] A11y keyboard focus control in the Input Component (#3585) This issue covers a number of things: 1. Blank aria-describedby - created #3713 <#3713> to fix 2. Duplication of tab stops in Firefox - unable to reproduce 3. Textarea text not read by screen reader - seems to be how JAWS handles textareas, saw same behavior w/ native one 4. Textarea initially blank in IE - This is caused by a core bug (angular/angular#14440 <angular/angular#14440> ), but we should update the example to work around it until its fixed. 5. Various a11y issues with the examples themselves Since 1-4 have some resolution or another issue tracking them, I will re-purpose this issue for tracking 5 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3585 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AVPBNvd668VUqbyHBnsSYD1dYFq7mQHwks5roEH5gaJpZM4Mb7IJ> . <https://github.com/notifications/beacon/AVPBNpXAMXtlwpcNFsqJZJfnFvWJtujaks5roEH5gaJpZM4Mb7IJ.gif>

[mmalerba]

The code for md-input-container actually automatically adds a label based on the placeholder. For example it transforms

<md-input-container class="demo-full-width">
  <textarea mdInput placeholder="Address">1600 Amphitheatre Pkway</textarea>
</md-input-container>

into something like this

<md-input-container class="demo-full-width">
  <textarea mdInput placeholder="Address" id="input1">1600 Amphitheatre Pkway</textarea>
  <label for="input1">Address</label>
</md-input-container>

I tried some various ways of labeling the textarea (see below) but it didn't make a difference in how JAWS read it. I think JAWS assumes textarea content will be too long and doesn't bother to read it all when you tab to the element.

<textarea placeholder="cool label">some content</textarea>

<textarea placeholder="cool label" id="test1">some content</textarea>
<label for="test1">cool label</label>

<textarea placeholder="cool label" aria-labeledby="test2">some content</textarea>
<label id="test2">cool label</label>

<textarea placeholder="cool label" aria-labeledby="test3" id="test4">some content</textarea>
<label id="test3" for="test4">cool label</label>

<textarea aria-labeledby="test5" id="test6">some content</textarea>
<label id="test5" for="test6">cool label</label>

[DaveBest99]

Interesting! It should not matter to the screen reader how much text is in the Textarea, but tests show that you are correct. Try using the role=textbox in the Textarea element: <textarea role=textbox>. I think that may fix the issue for most screen readers. Note: In most user agent implementations, the default behavior of the ENTER or RETURN key is different between the single-line and multi-line text fields in HTML. When user has focus in a single-line <input type="text"> element, the keystroke usually submits the form. When user has focus in a multi-line <textarea> element, the keystroke inserts a line break. The WAI-ARIA textbox role differentiates these types of boxes with the aria-multiline attribute, so authors are advised to be aware of this distinction when designing. See: WAI-ARIA Authoring Practices 1.1 - textbox Role http://w3c.github.io/aria-practices#h-textbox David From: mmalerba [mailto:notifications@github.com] Sent: March 22, 2017 01:44 PM To: angular/material2 Cc: David Best; Author Subject: Re: [angular/material2] A11y keyboard focus control in the Input example (#3585) The code for md-input-container actually automatically adds a label based on the placeholder. For example it transforms <md-input-container class="demo-full-width"> <textarea mdInput placeholder="Address">1600 Amphitheatre Pkway</textarea> </md-input-container> into something like this <md-input-container class="demo-full-width"> <textarea mdInput placeholder="Address" id="input1">1600 Amphitheatre Pkway</textarea> <label for="input1">Address</label> </md-input-container> I tried some various ways of labeling the textarea (see below) but it didn't make a difference in how JAWS read it. I think JAWS assumes textarea content will be too long and doesn't bother to read it all when you tab to the element. <textarea placeholder="cool label">some content</textarea> <textarea placeholder="cool label" id="test1">some content</textarea> <label for="test1">cool label</label> <textarea placeholder="cool label" aria-labeledby="test2">some content</textarea> <label id="test2">cool label</label> <textarea placeholder="cool label" aria-labeledby="test3" id="test4">some content</textarea> <label id="test3" for="test4">cool label</label> <textarea aria-labeledby="test5" id="test6">some content</textarea> <label id="test5" for="test6">cool label</label> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3585 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AVPBNkHn9RKo35K8vkAgcYhGy9NgsGF5ks5roV3zgaJpZM4Mb7IJ> . <https://github.com/notifications/beacon/AVPBNsmF1KwVIUNy448jTnLo8EpNL1mwks5roV3zgaJpZM4Mb7IJ.gif>

[mmalerba]

I tried adding role="textbox" aria-multiline="true" as well (though I don't think they should be necessary, the screen reader should know that it's the default role for this element). Didn't have any effect