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.
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.
In native WinForms programming there was the concept of "AutoComplete" with a mode "Append" where, as you type, the rest of the textbox would fill in with a suggestion which would be highlighted. If the user continued typing, that suggestion would naturally be replaced with the text entered, and the auto-complete suggestion would append again if available.
In web contexts, I have only seen auto-complete implemented as a selection dropdown below the input textbox (e.g. jquery autocomplete). There's also the input tag autocomplete attribute, but the options can't be controlled by javascript. Searching for "autocomplete" and "autofill" dead-end with issues relating to the autocomplete attribute.
If "AutoComplete Append" is used in a web context, does it go by a different name?
Is there a reason that this paradigm is avoided (or, doesn't even exist) in web development? (it seems particularly useful in mobile websites where screen real-estate is at a premium)
I have an html table and I want to be able to hide and show columns dynamically (based on certain values on page load). It could be a large number of columns I need to hide.
I was considering taking the values from the columns that I want to be hidden and putting their values in a data- attribute on the <tr> element to and avoid creating dom elements that aren't being shown in the ui. I need the values somewhere because they are used in click events.
Are there any best practices out there that say it is bad to load columns into a table and hide them with say display: none;, or am I just over thinking it and being anal and should just hide them with css?
I'm unsure of any types of practices particularly for this application. Also based on the information given so far.
The way you are doing it is not the best choice of going about this situation. You are taking data and putting them all in their own elements which not only clusters up HTML with unessessary elements (that are always hidden by CSS) but also can be more taxing then it has to on you and your viewers computer.
When you could be using the data attribute this is a great way to keep the information more consolated, less clutter, well organized, easy to read and manage. Also even when a element has the styling display:none it is still using the computer performance to render all of those elements.
You can read this thread that explains: Read More
I am a junior programmer working with Ruby on Rails. I am curious what is the best/elegant approach when you have to show content that has different states.
For example: I have a form on a page that can be shown, hidden (replaced with some text), or disabled (three states) - depending on users rights and other variables.
Is it best to put the form in a partial? Make different partial for different form states? Use helpers to wrap the logic?
Also, what's the best approach when I only have to add(or not to add) a class tag to a HTML element (decision made depending on some variables).
the show/hidden/view must be based on some business rule, so you should not implement that purely in the front-end. For instance, if you actually fetch the data but hide it using a style, the data is not really hidden. So it should be implemented in the middle tier "Controller" of your application.
The following is a fairly typical layout for admin pages (e.g. searching in a database and doing something with the results):
action dropdown
table header row with column names
second table header row with search filters for columns
result rows with a checkbox
search button
The user can set all sorts of filters, search, select some of the results with the checkboxes, then select an action from the dropdown, and the action and the selected row ids will be submitted to some processing script.
There are some basic expectations for such a control:
GET for searches, POST for actions
use the auto-sizing features of HTML tables so that columns can be narrow or wide depending on the content
reasonably cross-browser
I have been looking for a nice technique to achieve this, but everything I can think of seems to have serious disadvantages:
the simplest would be having two forms (a GET form for the search controls and a POST for the checkboxes), but the HTML4 DTD makes that impossible: I can either wrap the whole table in a single form or put separate forms inside every table cell (which is pretty useless).
alternately, I could use a different table element for every row and group them freely into forms, but then the column widths would not match and I would have to set fixed widths. (CSS3 table-* display types lack adequate support.)
HTML5 allows us to place input elements outside forms, and connect them with the form attribute, but that has even less support.
There is an ugly hack involving invalid HTML with forms directly wrapping tr elements, which seems to work but messes up the DOM, confuses Javascript libraries and is not exactly future-safe.
I can wrap the whole table in a single form, and change its method and action dynamically depending on which button was pressed, but that makes me dependent on Javascript; also, I don't want to submit search controls in the POST request and vice versa, it is unnecessary traffic. Also, when there are a lot of result rows, the search request might surpass the URL size limitations (just a few thousand characters in IE) because of all the checkboxes.
I could do the same but disable the unnecessary fields when the user submits the form. Beyond being horribly overcomplicated for such a simple task, this has various usability problems when the request is somehow stopped (e.g. user pressing ESC) and the user is left with a bunch if disabled form fields.
Is there a better solution I am not aware of?
Use AJAX. It allows you to define your own get/post data that is not form-dependent.