Any way to change the order in which RadGrid renders THEAD, TBODY, and TFOOT?

[Pavel]

When I try tabbing though my radgrid, it goes to the header, then the footer, then the actual body of the grid. I believe that this is happening because the tfoot tag is rendered before tbody. Is there any way to change that?

[Konstantin Dikov]

Hello Pavel,

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:

• HTML <tfoot> Tag

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.


Regards,
Konstantin Dikov
Telerik

[Dasha]

Konstantin,

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!

Dasha

[Konstantin Dikov]

Hi Dasha,

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.


Best Regards,
Konstantin Dikov
Telerik

[Dasha]

Konstantin,

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.

Thank you,

Dasha.

[Konstantin Dikov]

Hi Dasha,

Have you tried to handle the onkeydown event of the RadGrid's wrapping DIV element and manually focus the elements that you need?

<telerik:RadCodeBlock ID="RadCodeBlock1" runat="server">
    <script type="text/javascript">
        function gridKeyDown(element, ev) {
            // your logic
        }
    </script>
</telerik:RadCodeBlock>

<telerik:RadGrid runat="server" ID="RadGrid1" onkeydown="gridKeyDown(this, event)">
....
...

Regards,
Konstantin Dikov
Telerik

[Dasha]

Konstantin,

 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.

Dasha.

[SIEN]

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 :

https://github.com/whatwg/html/commit/94d55af9cda601ce675d15f6a0e52c9bb9c6afa9

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 ?

[Eyup]

Hello,

This was the standard order some time ago in HTML4 and then HTML5 made it optional:
https://stackoverflow.com/questions/18901950/thead-tfoot-and-tbody-order-in-html5
https://stackoverflow.com/questions/5574057/why-do-internal-table-sections-have-to-go-thead-tfoot-tbody-to-validate

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:
https://feedback.telerik.com/Project/108#

Regards,
Eyup
Progress Telerik

[Vance]

So what I am hearing is because you cannot move the tfoot below the tbody because it "may introduce a lot of breaking changes" then you are going to forgo accessibility? As this is a clear violation of WCAG 2.0 Focus Order (Section 2.4.3) then I would imagine that you will be noting on your documentation that the Radgrid does not meet WCAG 2.0 Accessibility Guidelines. This is a huge disappointment as one of the things that drew my organization to your tools was the fact that you state that you meet WCAG 2.0 Accessibility Guidelines yet you seem to be straying further and further away from that. Please tell me that you are going to work on this in the future.

[Rumen]

Hello Vance,

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
  
  

  <script>
      function OnClientLoad(sender, args) {
          var table = sender.get_masterTableView().get_element();
          var tFooter = table.tFoot;
          $telerik.$(tFooter).appendTo(tFooter.parentNode);
      }
  </script>
  <telerik:RadGrid RenderMode="Lightweight" ID="RadGrid1" runat="server" DataSourceID="SqlDataSource1" AllowPaging="true" ClientSettings-ClientEvents-OnGridCreated="OnClientLoad"
      AllowSorting="True" GridLines="None" OnSortCommand="RadGrid1_SortCommand" Skin="Silk">
      <MasterTableView AllowMultiColumnSorting="true">
          <PagerStyle AlwaysVisible="true" />
      </MasterTableView>
      <SortingSettings SortedBackColor="#FFF6D6" EnableSkinSortStyles="false"></SortingSettings>
      <HeaderStyle Width="100px"></HeaderStyle>
  </telerik:RadGrid>

Best regards,
Rumen
Progress Telerik

[Vance]

Hi Rumen,

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,

Vance Dhooge

[Rumen]

Hi Vance,

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.

• In Grid table, the footer tfoot element is rendered before the body tbody element

Best regards,
Rumen
Progress Telerik