aria-practices
aria-practices copied to clipboard
Develop example of a datagrid with advanced, spreadsheet-like features
Develop an implementation of the grid design pattern where:
- All cells have editable or interactive content and the Enter/F2 model of editing is available.
- A function is available that causes some cells to be marked read-only.
- Cells and rows are selectable and can be either moved or deleted.
An HTML template file for this example is now in the repo in examples/grid/advancedDataGrid.html.
first, i want to know whether use html table as base structure to implement advanced datagrid or spreadsheet-like feature
@LinBoLen does it make sense to add the same data to a HTML table? If so, yes :).
I agree that Aria should be used. How does one make a screen reader read A-1 notation while using a grid?
@frastlin, by A-1 notation, do you mean column and row cell addresses like in Excel where A1 is column 1 row 1 and C3 is column 3 row 3?
There are a wide variety of ways to enable such information to be automatically spoken. However, as a user, one thing that is extremely important to me is the ability to control if, how, and when such information is announced. Probably the best way for enabling that, at this time, is to use colheader and rowheader cells for the col and row titles. You could then also enable users to hide or show the address row and column.
This would work great! The only problem is that you would still hear the column and row number announced, so the message, using aria, would be something like: "cell content selected A1 column 1" Which is not the behavior in Excel or Google Sheets. I know for me, that extra column and row announcement would become really annoying after a while. There is also the "selected", but that is another issue. Is there any way to suppress the column and row announcements to match the behavior in Google Sheets and Excel? The only way I know of is to not use aria grid, but that defeats the point of using aria in the first place.
Frankly, it is significantly easier to build your own implementation of a spreadsheet than to use the proper Aria roles. I think there needs to be a spreadsheet element in HTML that has attributes that allow for callbacks and other things that normal cells have. But the actual management of aria in grids, in my experience, is gotten wrong 95% of the time. I have asked over 20 large companies how many blind users they have testing their products for UX and no one actually tests on blind users. This means that there is probably something that is not working correctly somewhere in the crazy globs of code in today's single page apps. Wrong implementations happen at all levels of Aria, but in Grids most often. Ease and speed are today's motto, so my boss always tells me to build as fast as possible at for the first iterations and refactor later. This means forgoing Aria almost altogether. I can build a spreadsheet app in the quarter of the time using live-regions.
any update on this?
Reading https://www.w3.org/TR/wai-aria-practices-1.1/#gridNav_inside I'm not sure how to handle when a cell contains multiple widgets and the widgets rely on Enter to trigger an action. Allowing only F2 to disable the grid navigation will require some knowledge from the user, specially on Apple keyboards which require Fn to be pressed. I was expecting that this demo would include this use case.
Reading https://www.w3.org/TR/wai-aria-practices-1.1/#gridNav_inside I'm not sure how to handle when a cell contains multiple widgets and the widgets relay on Enter to trigger an action. Allowing only F2 to disable the grid navigation will require some knowledge from the user, specially on Apple keyboards which require Fn to be pressed. I was expecting that this demo would include this use case.
Just implement the Menu Button pattern inside the cell. I don't see a conflict with the Enter key. When the user press Enter move the focus on the menu element, as long it has the focus it will also handle the arrows keydown events (you have to call stopPropagation to prevent the bubbling), when the focus goes back to the grid then you let the grid handle the arrows keydown events.
What you can't do is include multiple widget/buttons in the same cell, but you can split them in different cells and use CSS to make them look like the same cell.
Looking forward for this to completed!
@mcking65 Hi, I’d like to pick this up. I’ve been working on making our table implementation accessible at my organization and facing similar requirements. Please assign this to me if it’s available.
Hi @CodeThatBreak, the opportunity is definitely available. It would be a wonderful contribution to add this example.
I can't actually assign the issue in GitHub because you are not a member of the ARIA working group. However, that does not mean you can't work on it.
Given the scope of this issue, there are several things we may want to consider to help smooth the process and minimize unnecessary churn. I suggest:
- We sketch out a light-weight project plan.
- The plan maps out an iterative approach, starting with the simplest MVP as the first milestone and then adding on.
Might you be able to join a few meetings of the APG task force? Conversation can be very helpful when mapping out plans for an example like this. The APG TF meets on Tuesdays at 11:00 US Pacific time.
@mcking65 Thanks! Yes, I will create a project plan which breaks this task into milestones. I will also try to join the next meeting to discuss the plan. Could you please let me know how I can join the meeting?
I can send you a meeting invite. I will need an email address. You don't need to expose your email address here in the issue. You can send it to me at my gitHub email, which is a11ythinker at gmail.
If you would like to join today, I could adjust today's agenda. Otherwise, the next meeting would be November 18.
I haven't found the information on how to implement a Data Grid For Presenting Tabular Information with some cells containing only one item and others containing multiples. Should the focus be on the item if there's only one and on the cell if there is at least 2 elements? Should I always focus on the cells for clarity even if some only contains one?
I want to implement a calendar with rows representing 2 hours (8 to 10 / 10 to 12). In some cells, there's going to be only one slow, while on others, there maybe 2 or 3. (In my usecase, no event will overlap 2 rows)
That would be great if I could get an answer and if that could be implemented in the example :)