- From: Matt King <a11ythinker@gmail.com>
- Date: Tue, 29 Sep 2015 06:21:09 -0700
- To: "'Jason Kiss'" <jason@accessibleculture.org>
- Cc: "'PF'" <public-pfwg@w3.org>
Jason, I like your suggestion: "A composite widget containing one or more rows with one or more cells where some or all of the cells in the grid are focusable by using methods of two-dimensional navigation, such as directional arrow keys." I will make that change. I specifically avoided the words "tabular" and "data" because a grid is useful for much more than presenting data, and clarifying that is part of the resolution to issue 633. Now, on the separate topic of simple data tables that are sortable, I too find the description of table confusing. If you have a data table where the top row has links or buttons that sort, and each of them is a tab stop, I would put that in a table. However, if the entire table has only one tab stop and you can arrow across headers and/or data, then I would call it a grid. As I see it, the main point of the grid is to let assistive tech know to drop into an application mode so the arrow keys are available for navigation. In other words, the purpose of the role is to specify the interaction model because it effects how assistive technologies work. I can't think of any reason why an assistive tech developer or user would care whether you put your sortable data into a table or grid. They just want to consume and use it. Users won't care whether they tab to or arrow to sorting column headers unless there are a boat load of them and you made the tab sequence inefficient by not using a grid. Bottom line, I think it is an author decision whether or not to use a table element or a grid element to present sortable tabular data. And, authors should decide based on the type of interaction model they will offer. We will cover this topic in the authoring practices guide when we get to the grid role. We will have a version 1.1 of the APG that will be ready along with ARIA 1.1. With this in mind, though, we may want to consider some minor revisions to the table description. Matt King -----Original Message----- From: Jason Kiss [mailto:jason@accessibleculture.org] Sent: Monday, September 28, 2015 5:28 PM To: Matt King <a11ythinker@gmail.com> Cc: PF <public-pfwg@w3.org> Subject: Re: issue-633 Updates to grid and gridcell roles Hi Matt, Small question regarding this first sentence / short description: "A composite widget containing a collection of one or more rows that each contain one or more cells where some or all cells are focusable by using methods of two-dimensional navigation , such as directional arrow keys." I read this as saying each row in a grid has to have at least one cell that is focusable by two-dimensional navigation. I think it's the use of the word "each". Couldn't a grid that has multiple rows with interactive cells have some rows whose cells aren't interactive? If so, possibly rewrite as something like: "A composite widget containing one or more rows with one or more cells where some or all of the cells in the grid are focusable by using methods of two-dimensional navigation, such as directional arrow keys." Or, borrowing from the earlier definition for grid: "A composite widget that contains tabular data arranged in rows, columns, and cells, where some or all of the cells are focusable through methods of two-dimensional navigation, such as directional arrow keys." On a slightly related note, I'm still wondering about simple tables with sortable columns. Do these require the grid role? Based on the current definition of the table role [1], it would seem they do. But the newer definition of the grid role isn't as clear on this point, since a sortable table of otherwise static tabular data won't necessarily have two-dimensional navigation. Jason [1] http://rawgit.com/w3c/aria/master/aria/aria.html#table On Tue, Sep 29, 2015 at 10:47 AM, Matt King <a11ythinker@gmail.com> wrote: > Following is a summary of changes to grid and gridcell roles proposed > in the > mck_issue633 branch[1]. These changes incorporate feedback from the > Sep 17 ARIA meeting and enable grid to be applied to some of the > scenarios raised by issue 633. > > > > Changes to grid as compared to master[2]: > > 1. Expanded the definition of the role to clearly state grid can be > used to not only present tabular data but also group interactive > elements, such as a set of navigation links. > > 2. Clarified the intent and meaning of readonly when applied to grid. > > 3. Updated language related to colspan and rowspan to incorporate new > ARIA > 1.1 properties. > > 4. Removed unnecessary or eroneous references to treegrid. > > 5. Rearranged text to present requirements in a logical and easier to > comprehend sequence. > > 6. Made editorial changes to simplify wording, fix grammar errors, and > reduce use of passive voice. > > > > Changes to role gridcell as compared to master[2]: > > 1. Changed the word "active" to "focusable." in the phrase: "Gridcells > may be focusable, editable, and selectable." > > 2. Other editorial changes, e.g., adding reference links and using the > word gridcell in place of cell where it could affect the meaning. > > > > [1] mck_issue633 branch: > > http://rawgit.com/w3c/aria/mck_issue633/aria/aria.html#grid > > > > [2] master branch: > > http://rawgit.com/w3c/aria/master/aria/aria.html#grid > > > > Matt King
Received on Tuesday, 29 September 2015 13:21:40 UTC