Completed
Last Updated: 03 Sep 2019 16:13 by ADMIN
Release R3 2019
Created by: Sunil Sutar
Comments: 2
Category: TabStrip
Type: Bug Report
1

Hi Telerik team,

 

Few of our clients reported the following issue with respect to WCAG 2.0 SC 4.1.2 standard. (508 Standard and compliance) -

PracticeFunction (example)
Ensure ARIA roles, states, and properties are validLI has an aria-level attribute of 0, which is not an integer value greater than, or equal to, 1

 

Example: visit https://demos.telerik.com/aspnet-ajax/tabstrip/examples/wai-aria-support/defaultcs.aspx 

 

Observe the ul-li elements created for tabstrip. On each li element, there is aria-level attribute whose value is set to 0.

As per WCAG this value should start from 1. The value 0 is invalid. Refer: https://www.w3.org/TR/WCAG20-TECHS/ARIA12.html

 

Please let me know when are you going to fix this for compliance. 

--

Sunil

Completed
Last Updated: 03 Sep 2019 16:12 by ADMIN
Release R3 2019

Few of our clients reported the following issue with respect to WCAG 2.0 SC 4.1.2 standard. (508 Standard and compliance) -

 
Practice Function (example)
Ensure sub-lists are marked up properly This UL should only contain li elements (without an ARIA-assigned role), script elements (without an ARIA-assigned role) or template elements (without an ARIA-assigned role); or
 
elements with a role=listitem attribute; as direct child elements

 

Example: When Telerik Tabstrip has EnableAriaSupport=true, internally tabstrip is combination of ul-li with css to display the Tabs properly -

The html looks like as follows -  

<ul class="rtsUL">
    <li class="rtsLI rtsFirst" role="tab" aria-disabled="false" aria-level="0" aria-controls="LayoutPageView">
        <a accesskey="L" title="Layout" class="rtsLink rtsBefore" id="LayoutTab" href="#"><span class="rtsOut">
            <span class="rtsIn">
                <span class="rtsTxt">
                    <h2 class="RadTabStrip RadTabStrip_Default"><u>L</u>ayout</h2>
                </span>
            </span>
        </span>
        </a>
    </li>
    <li class="rtsLI" role="tab" aria-disabled="false" aria-level="0" aria-controls="SearchPageView" aria-selected="true" id="SearchTabStrip_active_tab">
        <a accesskey="S" title="Search" class="rtsLink rtsSelected" id="SearchTab" href="#">
            <span class="rtsOut">
                <span class="rtsIn">
                    <span class="rtsTxt">
                        <h2 class="RadTabStrip RadTabStrip_Default"><u>S</u>earch</h2>
                    </span>
                </span>
            </span>
        </a>
    </li>
    <li class="rtsLI rtsLast" role="tab" aria-disabled="false" aria-level="0" aria-controls="ResultsPageView">
        <a accesskey="R" title="Statewide Search Results 0 records" class="rtsLink rtsAfter" id="ResultsTab" href="#">
            <span class="rtsOut">
                <span class="rtsIn">
                    <span class="rtsTxt">
                        <h2 class="RadTabStrip RadTabStrip_Default">Statewide Search<u>R</u>esults (0)</h2>
                    </span>
                </span>
            </span>
        </a>
    </li>
</ul>


Observe the aria attributes which are on li elements. Is that really necessary considering the compliance? (as mentioned in practice and example).

 

Please let me know when are you going to fix this for compliance. 

--

Sunil 

Completed
Last Updated: 12 Oct 2015 12:01 by ADMIN
Observe the below video, demonstrating the issue :

http://screencast.com/t/pC1V29UwYQ83 

Adding another, not visible textarea to absorb the focus can be used as a workaround:

<telerik:RadTabStrip ID="rtsRFT" runat="server" Skin="Office2007" MultiPageID="rmpRTF"
    SelectedIndex="0" ShowBaseLine="True" OnClientTabSelected="OnClientTabSelected">
    <Tabs>
        <telerik:RadTab Text="Description" TabIndex="61" ToolTip="Click to view description"
            SelectedCssClass="SelectedTab" PageViewID="pDesription">
        </telerik:RadTab>
        <telerik:RadTab Text="Notes" TabIndex="63" ToolTip="Click to view notes" PageViewID="pNotes">
        </telerik:RadTab>
    </Tabs>
</telerik:RadTabStrip>
<div class="welcomeTab" style="height: 100%">
    <telerik:RadMultiPage ID="rmpRTF" runat="server" SelectedIndex="0">
        <telerik:RadPageView ID="pDesription" runat="server">
            <div>
                <telerik:RadEditor ID="txtDescription" runat="server" Width="100%" Height="250px">
                </telerik:RadEditor>
            </div>
        </telerik:RadPageView>
        <telerik:RadPageView ID="pNotes" runat="server" Height="100%">
            <div>
                <telerik:RadEditor ID="txtNote" runat="server" Width="100%" Height="250px">
                </telerik:RadEditor>
            </div>
        </telerik:RadPageView>
    </telerik:RadMultiPage>

</div>

<script type="text/javascript">
    function OnClientTabSelected(sender, args) {
        $telerik.$("#inboxId").focus();
    }
</script>
Completed
Last Updated: 03 Nov 2016 13:38 by ADMIN
Completed
Last Updated: 12 May 2016 10:35 by ADMIN
Completed
Last Updated: 27 Sep 2016 12:18 by ADMIN
ADMIN
Created by: Dimitar
Comments: 0
Category: TabStrip
Type: Bug Report
0

			
Completed
Last Updated: 02 Feb 2017 11:18 by ADMIN
Completed
Last Updated: 17 Apr 2018 15:16 by ADMIN
Workaround is attached. It focuses the first focusable element on the page and you can easily change that logic.


We have already taken upon ourselves the task of managing the keyboard navigation in a container (the pageview).

Please leave your comments how this should be fixed, because there are many options. For example:

   -  we can focus the first focusable element, in a fashion similar to the workaround. Caveat: the list is incomplete, there are more focusable elements. Also, non-sequential tabIndex values set by the developer will not be honored. We may implement logic that counts the tabIndexes and focuses the smallest one, but this is complex, error prone and browsers tend to return bad values for this attribute, especially when it is set to -1. Also, this may not be the desired behavior by the developers.

    - we can focus the pageview element. Caveat: you may be unable to enter its child inputs at all, depending on the page setup and the tabIndex values.

    - we can consider setting tabIndex to -1 for all focusable elements in other pageViews akin to the modal backgrounds for controls like window and tooltip. The goal being to let the natural flow of the page take over and the browser to do this job, not our JS code. Caveat: we can still break the navigation logic on the page and this also has low performance when changing many tabIndex attributes at once.