#9590 closed bug (fixed)

Opened October 07, 2013 02:09AM UTC

Closed October 18, 2013 10:28PM UTC

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

Attachments (0)
Change History (7)

Changed October 07, 2013 02:13AM UTC by cottrell comment:1

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

Changed October 07, 2013 11:58AM UTC by jzaefferer comment:2

owner: → cottrell
status: new → pending

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

Changed October 07, 2013 12:14PM UTC by cottrell comment:3

status: pending → new

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.

Changed October 07, 2013 12:47PM UTC by scottgonzalez comment:4

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.

Changed October 07, 2013 01:11PM UTC by cottrell comment:5

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.

Changed October 18, 2013 01:40PM UTC by jzaefferer comment:6

status: new → open

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

Changed October 18, 2013 10:28PM UTC by Jörn Zaefferer comment:7

resolution: → fixed
status: open → closed

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