- From: bryan rasmussen <rasmussen.bryan@gmail.com>
- Date: Fri, 8 Oct 2021 12:04:33 +0200
- To: WAI IG <w3c-wai-ig@w3.org>
- Message-ID: <CAHKsR699K1byqtXM0cibmghRA_ZNBto3dbtQqUhB_ZapRRsJdQ@mail.gmail.com>
another note on this - each glossary letter is implemented as a button, so you can see on whatever form fields overview your screenreader provides Glossary letter A, and so forth. so if you had selected A it was not visible in this list anymore, and if you have filtered then none of the others are shown either - but of course the glossary filter which is an input field is visible in the form elements view. On Fri, Oct 8, 2021 at 11:57 AM bryan rasmussen <rasmussen.bryan@gmail.com> wrote: > Hey, > > I've got a glossary - originally I started making it accessible with these > rules > > The currently selected level is removed from the reading / navigation > order - so for example if you have selected C you would hear > glossary letter c selected, if you then decided to navigate through the > list you would hear > > glossary letter A, glossary letter B, glossary letter D, glossary E.... > > however there is a filter on this glossary, which now I'm making > accessible. So if you write in the starting phrase anti, then of course > only words starting with a will be shown. > > so if I write anti and I tab from the filter field I hit the A button, and > then tab again I go into the list of terms starting with anti. This means > that the way for a keyboard user to be able to click on the letter B they > should go back to the input field and remove the filter text. > > The reason I did this was to keep people from having to tab through all > the glossary letters - but perhaps when the filter is done you should be > focused in the beginning of the words matching the filter and not turn off > the reaching of other glossary buttons? > > Thanks, > Bryan Rasmussen > >
Received on Friday, 8 October 2021 10:05:56 UTC