[Accessibility][Pagination] Using actual buttons instead of links

[Accessibility][Pagination] Using actual buttons instead of links

alnoalno Posts: 5Questions: 1Answers: 0
edited January 2022 in Feature requests

Hello, for accessibility purposes I realized that what looks like buttons in the pagination panel is currently built with links (<a> tags) instead of using actual buttons (<button> tag).

I tried to modify the generated DOM in order to replace links with buttons but it seems that Datatable doesn't handle the actions on the buttons and therefore this attempt failed.

It seems rather simple to change the way the DOM is generated in Datatable code (https://github.com/DataTables/DataTablesSrc/blob/master/js/ext/ext.paging.js lines 147 to 157), but I cannot figure why actual buttons are not correctly taken into account?

This question has an accepted answers - jump to answer


  • allanallan Posts: 62,086Questions: 1Answers: 10,180 Site admin

    I've just tried changing the a to a button and you can see the result here: http://live.datatables.net/kayiwoba/1/edit . It seems to work okay for me.

    However, I'm curious about how this would improve accessibility?


  • alnoalno Posts: 5Questions: 1Answers: 0

    Thanks Allan for your efforts!

    About your question about accessibility, http://web-accessibility.carnegiemuseums.org/content/buttons/ says:

    Screen readers handle links slightly differently than they do buttons. All links and buttons are tab-able, but pressing the Space key or Enter triggers a button, whereas pressing the Enter key only triggers a link.
    * Clickable actions: Use buttons to signal clickable actions, such as “download,” “sign up,” or “log out.” You may use links for less popular or less important actions. If you want something that looks and acts like a button, try to always use the button element rather than styling a link like a button.
    * JavaScript Trigger: If you want the user to trigger some kind of Javascript functionality by clicking it, use a button.
    * Navigation: If you want a user to navigate to a new page or to a different target on the same page, use an anchor element <a>.

    Datatable pagination buttons are definitely in the 1st and 2nd case ;)

    Do you think that your modification could be shipped in some next version of Datatable?

  • allanallan Posts: 62,086Questions: 1Answers: 10,180 Site admin
    Answer ✓

    Ah! That's brilliant - thank you. Yes - we'll get that into DataTables. It will drop in the next major release though (most likely v2) since it wouldn't be quite right to put in what would likely effect styling on a lot of sites with a patch release.

    I've got a ticket for it in our system now and will drop a reply back here when it is committed (although note DT2 is likely still some time away... I've started work on it, but there is still plenty to do :)).


  • alnoalno Posts: 5Questions: 1Answers: 0

    That's great news!

    Let me suggest a few other points which might be of great interest for the same commit...

    These would allow Datatable to be fully compliant with the French General Accessibility Improvement Toolkit (in French : RGAA, https://www.numerique.gouv.fr/publications/rgaa-accessibilite/methode-rgaa/criteres/#topic5), which is a very widely used toolkit used to evaluate accessibility in France and other French-speaking countries.

    • for the pagination buttons:

      • to add type="button" on buttons (otherwise, the button would react as a submit button on click)
      • to add aria-label="Page X"
    • to add role="nav" on the pagination block, e.g.
      <div class="dataTables_paginate paging_simple_numbers" id="example_paginate" role="nav">

    • for the table itself:

      • on the <table> tag, the attribute aria-describedby="example_info" refers to the next div about the number of displayed pages, but this attribute should provide a reference to a title or some element describing the content of the table; referring to the number of displayed pages doesn't bring useful information to the user. So removing this attribute and letting the developer add a title by using the <caption> tag could be a better option
      • on the <thead> and <th> tags: adding scope="col" would allow to specify a heading cell dedicated to vocal synthesis engines.
  • allanallan Posts: 62,086Questions: 1Answers: 10,180 Site admin

    Excellent points - thank you! I'll get them in as well. It is possible to us a caption at the moment (although I very rarely see it being used). v2 has APIs for the caption already committed which will increase its utility. Perhaps the correct thing to do is to remove the aria-describedby on the info element when there is a caption present?

    For the scope="col" - because of the ability to support "complex headers" (i.e. rowspan / colspan) we might need to require that the dev specify that in their template HTML for the table. I've still got work to do on the v2 column handling (that's the last really big thing for v2 in fact), so I will look into that then.


  • alnoalno Posts: 5Questions: 1Answers: 0

    Thank you very much Allan for your feedback and comments.

    To answer your question about the aria-describedby, I think it should be removed by default, but if a caption exists, it should refer to this caption. Making it possible for the developer to specify some other element to refer to in the config might be a plus.

    Best regards,

  • allanallan Posts: 62,086Questions: 1Answers: 10,180 Site admin

    That makes sense - thanks!

    You've obviously got some background in accessibility development - I hugely appreciate your input here. Do you work as an accessibility consultant?


  • alnoalno Posts: 5Questions: 1Answers: 0

    Hi Allan, you're welcome!
    Well I'm not exactly an accessibility guru :) I'm actually a full stack developer with some background in accessibility but on my current project I'm backed by an accessibility consultant who spent some time on exploring Datatable HTML output and provided her wise advice...

  • digitalchallengerdigitalchallenger Posts: 9Questions: 1Answers: 0

    Hello Allan,
    I took the example here & tested it,
    Alno is right, we need to make them as button as they take action & update the table dynamically.

    I see a accessibility problem, once the table is refreshed when I press tab focus is not consistent, some times it moves to previous link & some time it moves to a random element.
    Focus must remain on the button that triggered the action.
    Provide aria-pressed for the button so that users have feedback that page 3 is active

    I covered this subject on my accessibility blog
    Let me know if any more information is needded.

  • allanallan Posts: 62,086Questions: 1Answers: 10,180 Site admin

    I see a accessibility problem, once the table is refreshed when I press tab focus is not consistent

    This is in the paging buttons? I'm not actually seeing that behaviour I'm afraid. It is consistently stating on the currently focused button for me. I've just tried it with both Firefox and Chrome.

    Thanks for the link - we'll get that migration done!


  • digitalchallengerdigitalchallenger Posts: 9Questions: 1Answers: 0

    ok. i believe once we move to buttons i will retest on all browsers & screen readers.

Sign In or Register to comment.