E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Isabel Holdsworth
Date: Mon, Sep 10 2018 8:19AM
Subject: Table of selectable records
No previous message | Next message →

Hi all,

One of our pages contains a lengthy sortable table, where each row
represents an editable record from a database.

Does anyone have an example of the best way of making such a table accessible?

It looks visually like a spreadsheet. Should it behave like one from a
keyboard perspective? Should it be possible to traverse the table
using the arrow keys, and only have the Tab key move into and out of
the table itself? Currently the records are clickable but can't
receive focus, which isn't acceptable. But for each cell to be
focusable using the Tab key would prohibit all but the most determined
keyboard users from getting to the important content after the table.

I think that's probably the way to go, plus possibly have a "Select
row" button at the start of each row, but if there's a better way then
this is the place to ask :-)

Thanks as always, Isabel

From: Jonathan Avila
Date: Mon, Sep 10 2018 8:29AM
Subject: Re: Table of selectable records
← Previous message | Next message →

Hi, if the editable fields appear in a new page or pop up -- one interactive element per row in the focus order would likely be best. A grid which is one tab stop is generally reserved for interactive content such as where you edit directly in the cells.

If you can edit directly in the cells a grid might be an option or activating an edit link might make only that row have cells that appear active and in the focus order. Then you would need a button to accept or close the input for that row.

Jonathan

From: Birkir R. Gunnarsson
Date: Mon, Sep 10 2018 8:29AM
Subject: Re: Table of selectable records
← Previous message | Next message →

Does every cell in the table have functionality?
If so, you probably need keyboard interaction similar to the
Datepicker widget on this page:
https://dequeuniversity.com/resources/
(arrow keys up/down navigate to previous/next row, arrows left/right
navigate to previous/next cell, the table is essentially a single tab
stop).
Also look up grid examples in the ARIA Authoring Practices 1.1 spec.

If not, you can just code the column headers as buttons, indicate the
current sorting direction and make the first column into a series of
"select this row" checkboxes.
There's a sortable table example on the same page.



On 9/10/18, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> Hi all,
>
> One of our pages contains a lengthy sortable table, where each row
> represents an editable record from a database.
>
> Does anyone have an example of the best way of making such a table
> accessible?
>
> It looks visually like a spreadsheet. Should it behave like one from a
> keyboard perspective? Should it be possible to traverse the table
> using the arrow keys, and only have the Tab key move into and out of
> the table itself? Currently the records are clickable but can't
> receive focus, which isn't acceptable. But for each cell to be
> focusable using the Tab key would prohibit all but the most determined
> keyboard users from getting to the important content after the table.
>
> I think that's probably the way to go, plus possibly have a "Select
> row" button at the start of each row, but if there's a better way then
> this is the place to ask :-)
>
> Thanks as always, Isabel
> > > > >


--
Work hard. Have fun. Make history.

From: JP Jamous
Date: Mon, Sep 10 2018 5:59PM
Subject: Re: Table of selectable records
← Previous message | Next message →

Let's slice this one piece at a time.

1. The grid is responsive to mouse clicks but not to keyboard commands
To work around that, your developers would have to add on each row an Edit
button, for example on the right most column.
2. When the user tabs to the Edit button and activates it, the cells on the
same row should hide their content, which would be included in spans using
display: none
3. Through CSS, the developers would show the input fields that they already
have in each cell. That mouse user is interacting with some type of an
element.
4. The focus would get placed on the left most cell in the row and the user
can tab through it. (Note that no need for tabindex="0" because when the
grid loads, the input fields are already there, but hidden using CSS.
5. When the user is done editing, the last input field in that grid is the
Save button.
6. The user presses the Save button and the data is moved from the input
fields to the spans using inline variables. The spans are shown and the
fields are hidden.
For the most part, that is probably how this grid is working behind the
scenes but only responsive to mouse clicks. So your developers don't have to
recreate the wheels, rather modify the input fields and the JS functions.

I hope that helps.






--------------------
JP Jamous
Senior Digital Accessibility Engineer
E-Mail Me |Join My LinkedIn Network
--------------------

From: Isabel Holdsworth
Date: Mon, Sep 24 2018 4:53AM
Subject: Re: Table of selectable records
← Previous message | No next message

Yes JP, that's very helpful indeed. Thanks for taking the time to
write it out. I've created editable tables for CRM systems, but I
haven't instructed another developer on how to do it, so I'll
plagiarise your description and hopefully our tables will be perfectly
accessible.

Or perhaps they'll choose to wait for Tenon's accessible React
components and see what they have to offer.

Exciting times!

Thanks again, Isabel

On 11/09/2018, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> Let's slice this one piece at a time.
>
> 1. The grid is responsive to mouse clicks but not to keyboard commands
> To work around that, your developers would have to add on each row an Edit
> button, for example on the right most column.
> 2. When the user tabs to the Edit button and activates it, the cells on the
> same row should hide their content, which would be included in spans using
> display: none
> 3. Through CSS, the developers would show the input fields that they
> already
> have in each cell. That mouse user is interacting with some type of an
> element.
> 4. The focus would get placed on the left most cell in the row and the user
> can tab through it. (Note that no need for tabindex="0" because when the
> grid loads, the input fields are already there, but hidden using CSS.
> 5. When the user is done editing, the last input field in that grid is the
> Save button.
> 6. The user presses the Save button and the data is moved from the input
> fields to the spans using inline variables. The spans are shown and the
> fields are hidden.
> For the most part, that is probably how this grid is working behind the
> scenes but only responsive to mouse clicks. So your developers don't have
> to
> recreate the wheels, rather modify the input fields and the JS functions.
>
> I hope that helps.
>
>
>
>
>
>
> --------------------
> JP Jamous
> Senior Digital Accessibility Engineer
> E-Mail Me |Join My LinkedIn Network
> --------------------
>
>
>