Imagine my application has a list of supported languages. I'm looking for a UI element which allows to select a subset of the supported languages plus make one of them the default.
At first, I thought to use a list with two checkbox columns but the user will be surprised when she activates one in the "default" column because that will deselect the current default. I could use radio buttons but that also feels clunky (and a waste of screen space).
The next idea was to have two lists, one with the available languages and one with the active ones. But how would the user select the default in this case?
Our current solution works with two lists:
Active Available
* English Italian
French <=> Greek
German
You can drag and drop elements between the lists to make a language active or not. The first element of the left list is the "default". In the UI, we give it a special style, so users can easily recognize "this language is special." A tooltip (and the documentation) reveals "this is the default language."
To select a different default language, just drag one of the elements on the left side to the top of the list.
Related
My team and I are building a web-app for a customer who has requested custom functionality pertaining to data-tables: upon clicking the header of a given table column, the table then becomes sorted based on that column. This functionality is already implemented.
However, an important stipulation of the contract is compliance with WCAG 2.1 accessibility standards. Aside from within tables, we have aria labels in all the right places, but it's unclear how we should go about making this custom table behavior more accessible-- particularly for screen-reading tech. As of now, the table header cells themselves have event-handlers for clicks to trigger the functionality, but no semantic <button>s are involved in this process, which is where things start to feel a little wrong for me.
The table header cells are also focusable, so that users can use Enter or Spacebar to toggle the functionality that way. How should we handle communicating this behavior to the user, especially those using screen-readers? Since this functionality is not typical of what is otherwise a fairly standard table, guidelines and requirements from WCAG and other sources are unclear.
I apologize, but I am unable to provide a screenshot or code snippet due to the sensitive and proprietary nature of the content.
For any table that is readonly and also is meant not to be sorted etc. standard HTML tables should be used.
In your case please use the design pattern grid from the ARIA 1.1 guideline (chapter 3.12 under this link https://www.w3.org/TR/wai-aria-practices/#grid)
Your customer should familiarize himself about the keyboard commands ARIA declares for grids. Manipulating theese keys will mean much work to you and irritating the screen reader user and hurt WCAG.
Here are two decent examples of accessible sortable tables:
https://assets.cms.gov/resources/framework/2.0/Pages/datatables.html
https://adrianroselli.com/2021/04/sortable-table-columns.html
The first one is a little too wordy with it's announcement to screen readers and could be shortened up for a better user experience and the second one is a little too terse with just saying "title button". We need a Goldilocks example between the two but both examples show how to use a <button> in the table header and the use of aria-sort.
I didn't hear anything in your OP that would indicate that a grid should be used. Note that the first sentence in the grid definition says that a grid is "a composite widget containing a collection of one or more rows with one or more cells where some or all cells in the grid are focusable by using methods of two-dimensional navigation, such as directional arrow keys." In other words, if the user will be able to navigate the table using the up/down/left/right arrow keys (as if you're navigating through a spreadsheet), then a grid is appropriate. But if you have a "normal" table that does not allow navigating cell by cell, then a standard <table> can be used. Just add buttons to your column headings (<th>) that allow the table to be sorted.
I have an existing (search autocomplete) component that needs to be made accessible.
The component consists of a text input, which on input opens a combobox (with data fetched from the server) which shows the data in a grid-like layout with additional information like categories and some visual styling (the icons are purely decoration and can probably be hidden from screen readers). To my understanding, this would be implemented according to this example.
However, the options in the combobox are also grouped by type (eg. "Content", "Categories"), which, in a combobox using a listbox, would be implemented using the 'group' role like in this example. I know this is an editor's draft, but in the spec it is already in the working draft.
Now, is it possible to implement this in an accessible way, having both the grouping (ideally with the grouping semantic available to the screen reader, like with role='group') and the additional information (ideally in gridcells, as in the example)?
Or will I have to resort to hiding either of them, to either using a listbox and hiding the additional information from the screen reader, or by using a grid and having either no grouping or just rows that are non-interactive and have no semantic meaning?
Note: I have no influence over the styling/layout, only what is presented to the screen reader. I am aware that this is not the most ideal starting point.
I have a similar question to the one asked here.
HTML select tag autocomplete
A list on a website I use had a large (~20,000) number of entries. So when I highlight an option and start typing to find an entry I'm looking for, the browser (Chrome) can't find the option quickly enough. If I tried to find an entry, for example, called 'Apple', I would begin typing the word and the list would highlight an entry beginning with 'A', then another entry beginning with 'P' and so on. It is able to find strings of characters (eg, an entry beginning with 'Ap') but only if I type at a very specific speed.
My question is, as a user, are there any settings, browser or otherwise, that I could access to allow me to search this list? Perhaps to change the speed I need to type in order to search for strings of characters. In Chrome's settings (and advanced settings), there appear to be no settings related to this.
Thanks.
As a user, there's not much that can be done. You don't have access to the underlying data structures of the <select> element, so the browser has to search through the <option>s one at a time.
As a developer, the trick is to not search the <select> box. Instead, use it as the raw data to build a searchable data structure when the box first loads, and then run your searches on that instead. The result of a search should contain the appropriate index into the <select> box, and then you just select that.
A trie (not to be confused with a binary search tree) might work well for something like this. At each node in the trie, you store the index of the first <option> element whose prefix matches the string up to that point. Then you branch off to child nodes corresponding to the next character in the string. John Resig, of jQuery fame, did some work with JavaScript tries a few years ago. He was using it on a text dictionary, but it should be adaptable to something like this.
Is there any way to make select, which allows multiple selections look like ordinary?
Like a drop-down, you know…
<select multiple="multiple"></select>
look like
<select></select>
http://jsfiddle.net/UKf5Y/3/
Well, no. If there were, how would the user use it to select multiple items?
The only way that a multiple selection works is because all of the items are displayed at the same time and they can click-and-drag or click while holding down a modifier key.
If it looked like a drop-down box, how would you navigate to a second item without deselecting the first?
The styling of a select list, as well as many different elements in HTML (notably the input[type='file'] element, is really dependent on the browser. If you're looking to make it visually more appealing / different, you'll really need to use some JavaScript and use an "interface" to your select. Some really nice JavaScript libraries for select lists are jQuery Multiselect, jQuery UI Multiselect and select2, maybe you should look at those.
It's worth noting however that only select2 supports the single/multiple variants, and the styles still do look different, but how else would you be able to see multiple selections at one time? You could design your own solution which did look identical, but I think more than anything this would be misleading.
I'm implementing a star-rating system on a product page. The current one is bloated and couldn't be considered semantic.
Is there a better way to approach ratings in HTML5 now (with for e.g. the <range> input)? Or failing that, what is the appropriate way to write the markup for a star-rating system?
For voting it is semantically a form (not a set of links, because this action has side effects, so must it use POST method). Stars could be radio buttons (with <label>!) or submit buttons (unfortunately this will be tricky to style).
<input type=range> would be more appropriate if you had rating in % or some larger scale. For a typical 1-5 rating it might not be the best solution:
The input element represents a control for setting the element's value to a string representing a number, but with the caveat that the exact value is not important, letting UAs provide a simpler interface than they do for the Number state.
For presenting the ratings, HTML doesn't have any specific elements, but you could use hReview or hReview-aggregate microformats or equivalent microdata (Google likes them).
I think the range input looks ideal for this job. In HTML <5, I think the most semantic way to do this is via a series of radio buttons. These can be styled to look like stars and scripted to behave as one would expect rating-stars to behave.
Additionally, for a static representation of a star rating the <meter> element should be suitable.
The meter element represents a scalar measurement within a known
range, or a fractional value; for example disk usage, the relevance of
a query result, or the fraction of a voting population to have
selected a particular candidate.