Sto prendendo un'altra decisione nel trovare un modo per rendere compatibili i componenti Ext JS Combobox con IE/JAWS. Attualmente stiamo usando il seguente markup:Markup compatibile IE per combobox ARIA
<div role="presentation" id="combobox-1011">
<label id="combobox-1011-labelEl" for="combobox-1011-inputEl">
<span>Choose:</span>
</label>
<div id="combobox-1011-bodyEl" role="presentation">
<!-- This wraps both input and triggers -->
<div id="combobox-1011-triggerWrap" role="presentation">
<div id="combobox-1011-inputWrap" role="presentation">
<input id="combobox-1011-inputEl" type="text" name="choose"
role="combobox" aria-readonly="false"
aria-haspopup="true" aria-expanded="true"
aria-autocomplete="none" aria-owns="boundlist-1014-listEl"/>
</div>
<!-- Trigger element styled to look like a button -->
<div id="combobox-1011-trigger-picker"></div>
</div>
<!-- This is used to announce input validation errors -->
<div id="combobox-1011-ariaErrorEl" role="alert" aria-live="polite"></div>
</div>
</div>
<div id="boundlist-1014">
<div id="boundlist-1014-listWrap">
<ul id="boundlist-1014-listEl" role="listbox" aria-hidden="false">
<li role="option" tabindex="-1" aria-selected="true" id="ext-element-7">Option 1</li>
<li role="option" tabindex="-1">Option 2</li>
</ul>
</div>
</div>
Questo funziona abbastanza bene in Firefox con JAWS e NVDA; tuttavia JAWS in IE annuncerà il campo di immissione come "modifica" quando focalizzato.
Dopo aver letto WAI-ARIA Combobox pattern fino a quando ho incrociato gli occhi e sperimentato per diversi giorni, sono pronto ad ammettere che IE è troppo buggato per far funzionare le combo in modo affidabile. O forse non è lo stesso IE, ma piuttosto il bridge MSAA/UIA come suggerito in this comment. Questo potrebbe anche essere vero perché ho trovato almeno una combinazione di attributi ARIA che sembra funzionare bene in IE8/XP con JAWS (usa MSAA) ma non ha funzionato in IE11/Win7 con JAWS (MSAA/UIA).
Il markup può essere modificato in una certa misura; ciò che non posso cambiare è l'esistenza degli elementi di avvolgimento come bodyEl, triggerWrap e inputWrap. Questi elementi sono necessari per applicare le classi CSS pertinenti, rendere gli elementi indicatori di errore quando la convalida dell'input fallisce, ecc.
Un altro vincolo è che l'elemento listbox viene reso all'esterno dell'elemento componente. Questo può essere cambiato ma non facilmente; anche renderlo adiacente all'input non sembra affatto di aiuto. Vale la pena ricordare che la lista stessa viene visualizzata dinamicamente alla prima espansione, con l'attributo aria-owns aggiunto dopo il fatto.
quello che ho provato finora:
Posizionamento
role="combobox"sull'elemento esterno. Non fa nulla di utile, combo non è riconosciuto come tale.Inserimento
role="combobox"e attributi rilevanti suinputWrap. In questo modo, IE annuncerà "Choose edit combo" quando l'input è focalizzato direttamente; quando tocchi da un altro elemento, annuncerà invece il ruolo dell'elemento, insieme all'etichetta combinata. Abbastanza divertente ma non molto utile.Inserimento
role="combobox"sutriggerWrape assegnazione dirole="button"allo pseudo-pulsante di attivazione. In teoria questo dovrebbe essere vicino al primo schema di progettazione, ma la combo non è riconosciuta come tale.Molte altre combinazioni ad hoc, molte delle quali non ricordo più.
L'unico modo di lavoro quasi sta ponendo ruolo combobox sulla inputWrape rendendo inputWrap tabbable invece l'ingresso effettivo. Ciò corrisponde al markup in this example che sembra essere più o meno funzionante con IE/JAWS; tuttavia questa soluzione è molto indesiderabile dal momento che apre la scatola di Pandora piena di bug per la gestione del fuoco molto pelosi.
Sfortunatamente gli strumenti di controllo dell'accessibilità non sono del tutto utili in questo caso, perché quello di cui ho bisogno è una soluzione per i bug nell'implementazione esistente, non una conformità standard più severa.
Un altro ostacolo a una migliore comprensione è l'ambiguità nelle specifiche WAI-ARIA. Ad esempio, per il primo modello è necessario che "il primo elemento all'interno della casella combinata sia un campo di testo di input".Questo significa prima elemento strutturale (ad esempio non di presentazione), o assolutamente primo elemento figlio? La modifica del markup in entrambi i casi non sembra fare alcuna differenza per IE, a meno che il wrapper <div role="combobox"> non sia tabbable.
Scusate se questo post sembra più un rant;) ma in realtà è una domanda: c'è un modo per aggirare le carenze di IE applicando gli attributi ARIA ai nostri elementi di markup esistenti? In caso contrario, cosa può essere modificato per farlo funzionare (escludendo il wrapper tabbable)? E i punti bonus finali per approfondimenti su perché non funziona come previsto.
Apprezzerei qualsiasi suggerimento e suggerimento. Sono molto preoccupato che le nostre combo non siano completamente accessibili in IE e vorrei risolvere questo problema se possibile. Ho ancora una debole speranza che qualcuno là fuori possa possedere una ricetta di ingrediente segreta per rendere felici sia IE che JAWS l'uno con l'altro. ;)
UPDATE: Ecco uno example fiddle. Nota come combo è annunciato correttamente in Firefox ma è solo "edit" in IE11 (testato con JAWS 16). Per risultati migliori con lo screen reader, ti consiglio di utilizzare l'opzione Open outside of Fiddle disponibile nel menu Condividi.
Potresti fornire un jsFiddle? –
@BasvanStein Aggiornato con un violino, vedi sopra. Non è possibile utilizzare jsFiddle per questo dato che non hanno l'ultimo Ext JS ma anche Sencha Fiddle dovrebbe funzionare. –