Opened 4 years ago

Closed 4 years ago

#9590 closed bug (fixed)

Dynamically adding input field breaks auto-complete's accessibility for screen readers

Reported by: cottrell Owned by: cottrell
Priority: minor Milestone: none
Component: ui.autocomplete Version: 1.10.3
Keywords: Cc:
Blocked by: Blocking:

Description

I have discovered a problem where if I dynamically add an input field with auto-complete the accessibility features are broken with respects to to screen readers. I notice that in this case the addition does not include the accessibility helper.

<span role="status" aria-live="polite" class="ui-helper-hidden-accessible"></span> 

Simple example that breaks accessibility for screen readers (tested using JAWS and NVDA) JS Fiddle

<body>

<div id="test" class="ui-widget">
  <label for="tags">Tags: </label>
</div>

<script>
var availableTags = [
      "ActionScript",
      "AppleScript",
      "Asp",
      "BASIC",
      "C",
      "C++",
      "Clojure",
      "COBOL",
      "ColdFusion",
      "Erlang",
      "Fortran",
      "Groovy",
      "Haskell",
      "Java",
      "JavaScript",
      "Lisp",
      "Perl",
      "PHP",
      "Python",
      "Ruby",
      "Scala",
      "Scheme"
];

var input = $( '<input id="tags">' );
input.autocomplete({
      source: availableTags
});

$('#test').append( input );
<script>
</body>

Upon reviewing the source of the ui widget where the accessibility helper is being added appears to assume the node already exists on the dom

//inside the _create function
this.liveRegion = $( "<span>", {
   role: "status",
   "aria-live": "polite"
})
.addClass( "ui-helper-hidden-accessible" )
.insertBefore( this.element );

Cheers, Rylan

Change History (7)

comment:1 Changed 4 years ago by cottrell

Opps forgot to include the jsfiddle http://jsfiddle.net/dq5gq/2/

comment:2 Changed 4 years ago by Jörn Zaefferer

Owner: set to cottrell
Status: newpending

Is there a reason for waiting with the DOM insertion after applying the widget? That is, can you append first, then initialize the autocomplete?

comment:3 Changed 4 years ago by cottrell

Status: pendingnew

In our scenario the controls are constructed asynchronously, so the append happens very late in the process.

Though for accessibility it should be atomic, the order of events should not matter. Auto-complete does not require the node to be appended first, neither should it's accessibility sub-component.

comment:4 Changed 4 years ago by Scott González

We could potentially just append the live region to the body instead of placing it before the input. I don't think the proximity in the DOM matters.

I'll leave this as new until we can verify whether this will work.

comment:5 Changed 4 years ago by cottrell

In the meantime a simple work around I found was to create a div and append the input to that div, then append that div further down the pipeline. Though a better solution should be sought, because when I was researching the problem to ensure it was a bug, I came across many stack overflow solutions that utilize auto-complete in an inaccessible way.

comment:6 Changed 4 years ago by Jörn Zaefferer

Status: newopen

Appending to the body fixes the issue. I've tested with VoiceOver on OSX and I've put together a PR: https://github.com/jquery/jquery-ui/pull/1113

comment:7 Changed 4 years ago by Jörn Zaefferer

Resolution: fixed
Status: openclosed

Autocomplete: Append liveRegion to body to support detached init. Fixes #9590 - Dynamically adding input field breaks auto-complete's accessibility for screen readers

Changeset: 7b9c810b9ac450d826b6fa0c3d35377178b7e3b3

Note: See TracTickets for help on using tickets.