12 Answers, 1 is accepted
This is the standard order of the thead, tfoot and tbody elements and some detailed information on the matter could be found in the following article:
As for your question about a way for changing the structure, I am afraid that there is no such built-in functionality of the grid that will allow you to achieve this, but if you need to change the tabbing order you can get reference to the controls and set their Tab Index.
Hope this helps.
I'm trying to allow customers to tab into the data rows by setting the AccessKey value of the first cell in the first row. I see the accessKey value set correctly, but when pressing the required key combination, the whole tbody element gets highlighted, and upon pressing the tab key, the selection skips to the footer. Do you have any other suggestions for forcing the data rows to be tabbed after the column headers?
I'm afraid we cannot use the TabIndex property, since in a Sharepoint environment I cannot control the tab indexes of other elements on the page, and I also have to account for potentially having more than one grid on the page. Our requirement is to allow for screen readers to read all the data top-down as it visually appears on the page.
Thank you for your help!
I am not sure that I understand exactly what you have tried and to which element you have set the accesskey attribute, but please note that this is applicable for "<a>, <area>, <button>, <input>, <label>, <legend>, and <textarea>" elements and although that you could focus any element (in html5), the tabbing will move the focus across those elements only.
As for the TabIndex property of the INPUT elements, there should be no problem to achieve this in SharePoint and you only need to get reference to the editors within your RadGrid and set their TabIndex property in ascending order (that order could be used for multiple grids as well, so this is also not a problem).
Finally, please note that this requirement is not related to RadGrid in any way, because the tabbing functionality follows the browser behavior and if you need to customize it you will have to either use the TabIndex or handle the keydown event of your document and manually focus the elements when the tab key is pressed.
I tried adding a label to the first non-empty cell in the grid <label accessKey='O'>test</label> just to get something working. I see the label added properly and rendered, but pressing alt+O (or control option O on a mac) highlights the tbody element, and the next tab press sends me down to the footer.
Any time I set the tabIndex to anything higher than 0, that is then the firs element focused on the page. I need the page to be read top-down, and I can't control any of the SharePoint elements on the page.
While I understand that the functionality follows the browser behavior and the suggested html practices, I was hoping you would have some work-around available, granted Telerik's 508-compliancy statements. We are currently trying to pass the 508-compliancy testing, and this is one of the red flags that came up during the preliminary testing of our product. Users want to be able to read the grid top-down, and reading the footer prior to reading the data is confusing, especially for a blind person.
Have you tried to handle the onkeydown event of the RadGrid's wrapping DIV element and manually focus the elements that you need?
Thank you for this suggestion. I'm now able to set focus to the first data cell of the grid triggered by a key combination.
Hi, we obteined a remarque from an accessibility audit that says that we should render tfoot after tbody.
In effect, newer version of HTML 5 don't even allow tfoot to be rendered before tbody due to accessibility concerns :
Now, before using TabIndexes to resolve this issue, is there any hope to gat this behaviour in future versions of Telerik ? or is this option already supported out of the box ?
This was the standard order some time ago in HTML4 and then HTML5 made it optional:
Now the new arrangement may be considered as a requirement. I am afraid the rendering of RadGrid cannot change currently since it may introduce a lot of breaking changes. Nevertheless, you can log this idea in our public portal:
First of all I'd like to thank you for your valuable feedback! It is much appreciated!
The accessibility of the suite is one of our primary goals.I cannot help but agree that the W3C specs have changed for HTML 5.1 and now the tbody tag should precede the tfoot one.
Since it would be a huge breaking change not only for the rendering of the component, but also in the functional logic, it would be hard to predict and even cover all possible side effects that such an improvement may cause. That's why, we do not have short term plans to make it in the source but we will gladly assist everyone who experiences problems with it to overcome them. You can find below a couple of approaches you can choose from to solve the issue:
- Use Static Headers as shown here and here - in these demos the pager is placed in the tBody.
- or Use MultiHeaders - Overview demo - in this demo the pager is placed in the tBody.
- or Use RenderMode="Classic"
- or Programmatically append the tfoot element to the end of it parent
Thank you for your response.
In the two Static Headers examples you mention above it looks like the goal is achieved by setting the grid to allow scrolling which I had actually tried and although it does solve the issue of the pager being rendered below the table columns and would essentially meet WCAG 2.4.3 it breaks the functionality of the table because it places the table header columns in a completely separate table within a separate div therefore rendering the data in it's own table with no table columns. A user using assistive technology would get lost in a table with no headers so this does not make the table accessible. If anything it makes it worse.
The MultiHeaders demo you linked to does not solve the issue at all as the pager is still in the tfoot which is rendered above the tbody. I must note also that if you add a column summary this renders in the tfoot as well so this does not help that either.
I will look at the programmatic solution you listed above and check to see if this is a viable solution but even if it does work this does not mean that your tool meets accessibility guidelines. To truly meet the guidelines each of your controls would need to meet the guidelines out of the box with no programmatic re-rendering.
My question is this. Do you have an accessibility team there? How are they trained? I go to a lot of accessibility training's and conferences throughout the country and have not met anyone from your team. This is just a curious question.
Thank you for sharing your feedback and findings with us.
I cannot help but agree that to fully satisfy and meet the accessibility guidelines, the component should not re-render its HTML via programmatic interference and once again I'd like to note that the provided ideas in my earlier reply are workarounds, but not a built-in solution.
Presently, the grid control passes WCAG 2.0 validation (this is tested with Compliance Sheriff and WAVE), but without satisfying the HTML 5.1 requirement the tbody to precedes the tfoot. This is something important that we strive to fix in the future, but will require time to ensure that this regression won't effect the majority of projects, grid customizations and tests.
As to your questions: We have accessibility specialist across the teams and they develop their proficiency from sources like: W3C specs, IAAP CPACC Certification, IAAP WAS Certification, Pluralsight and other training courses.
Nevertheless, here is the feedback portal item where you can share your comments and cast your vote.