• Hi TEC team! It doesn’t look like I can open an issue on your GitHub repo, so I’m posting the issue here and I’m hoping you will fast track a fix. Let me know if you have any questions.

    This issue pertains to the “Add to Calendar” button on the events single.

    The code for this element is:

    <div class="tribe-common-c-btn-border tribe-events-c-subscribe-dropdown__button" tabindex="0">
    <svg class="tribe-common-c-svgicon tribe-common-c-svgicon--cal-export tribe-events-c-subscribe-dropdown__export-icon" viewBox="0 0 23 17" xmlns="http://www.w3.org/2000/svg">
    <path fill-rule="evenodd" clip-rule="evenodd" d="M.128.896V16.13c0 .211.145.383.323.383h15.354c.179 0 .323-.172.323-.383V.896c0-.212-.144-.383-.323-.383H.451C.273.513.128.684.128.896Zm16 6.742h-.901V4.679H1.009v10.729h14.218v-3.336h.901V7.638ZM1.01 1.614h14.218v2.058H1.009V1.614Z"></path>
    <path d="M20.5 9.846H8.312M18.524 6.953l2.89 2.909-2.855 2.855" stroke-width="1.2" stroke-linecap="round" stroke-linejoin="round"></path>
    </svg>
    <button class="tribe-events-c-subscribe-dropdown__button-text">
    Add to calendar </button>
    <svg class="tribe-common-c-svgicon tribe-common-c-svgicon--caret-down tribe-events-c-subscribe-dropdown__button-icon tribe-events-c-subscribe-dropdown__button-icon--rotate" viewBox="0 0 10 7" xmlns="http://www.w3.org/2000/svg"><path fill-rule="evenodd" clip-rule="evenodd" d="M1.008.609L5 4.6 8.992.61l.958.958L5 6.517.05 1.566l.958-.958z" class="tribe-common-c-svgicon__svg-fill"></path></svg>
    </div>

    You have added tabindex=”0″ to the div, which contains the button. This inserts the div into the tab order on the page and allows it to receive keyboard focus. On focus, the div is styled similarly to how it’s styled on hover, so it looks like an actionable button, however pressing Enter/Return on a keyboard does nothing because it doesn’t have button functionality added to it with JavaScript. It also doesn’t have the ARIA it needs to be read out appropriately to a screen reader user.

    Effectively, adding this tabindex makes the element appear broken.

    The actually button that a keyboard-only user needs to find to engage the add to calendar dialog is one tab stop further, however it has no discernable focus state, which is very confusing for a sighted keyboard only user.

    Fix #1: please remove the tabindex=”0″ from this div:

    <div class="tribe-common-c-btn-border tribe-events-c-subscribe-dropdown__button" tabindex="0">

    There are also a few issues with the button itself for people for screen reader users. Thow it’s not styled this way, this button essentially functions like an accordion that opens and closes a content area. Since you can tab beyond it without closing it and then can tab back through the links.

    Fix #2: please add this ARIA to the button so that screen reader users will know what the button does:

    <button class="tribe-events-c-subscribe-dropdown__button-text" aria-expanded="false" aria-controls="subscribe-dropdown" aria-label="View links to add event to your calendar">
    Add to calendar </button>

    Two things need to happen for this ARIA to work. First, you need to add an id of subscribe-dropdown to

    <div class="tribe-events-c-subscribe-dropdown__content" style="display: block;">

    That will allow the aria-controls to reference the element.

    Second, you need to write Javascript that changes the value of aria-expanded from false to true when the element is opened (and then back to false if it is closed again).

    Here’s a great example of an accessible accordion.

    Once the modal is opened the elements within it have an outline on keyboard focus because of this CSS:

    .tribe-common a, .tribe-common a:active, .tribe-common a:focus, .tribe-common a:hover, .tribe-common a:visited {
        color: var(--tec-color-text-primary);
        outline: 0;
        text-decoration: none;
    }

    Fix #3: please remove .tribe-common a:focus from this and add it in its own CSS declaration that does not include outline:0;

    You should never remove the outline on :focus or :focus-within. That is an important accessibility feature for keyboard-only users.

    I appreciate you making these fixes. Thanks!

    The page I need help with: [log in to see the link]

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Gustavo Bordoni

    (@bordoni)

    HI @alh0319,

    First I want to thank you sooo much for your report here, first I will address the GitHub issues, we disabled it because a lot of our customers would end up opening Issues there as support tickets, which added a weird load to our Developers day to day tasks, that is why we blocked it, but this decision has been like this for a couple years, now there are much better tools in GitHub to avoid that, so we might revisit that.

    Number 1 is the only one I am not 100% sure on the reasoning just yet, I’ve asked one of the developers that worked on that project to take a look at your comment to see if we can remove it without any side effects.

    Number 2, it’s an easy fix. We should be able to include it in a future release for sure. I will create a ticket and make sure it gets attention soon. Cannot promise you a date as developers are not in charge of the whole timeline of fixes.

    Number 3, I am pretty sure that must have been a design decision that didn’t get enough attention when included in the codebase. I believe that accessibility here is probably more important. Same as the above it’s an easy enough fix, but requires some QA to make sure there are weird side effects.

    Again thank you so much for your comment, our team takes accessibility seriously but with such a huge codebase and a lot of legacy code we are unsure some times what are the things customers are facing on that front. If you find any other problems in the future please reach out here (mention me) or on the WP.org Slack directly to me, so I can direct it to the correct team.

    Best Regards,

    @alh0319 Thanks for posting this out in the open, I loved that you posted this here and especially on Mastodon. I follow you there and whenever you post accessibility-related things about plugins — I like to go and check out what the issues were and how to fix those.

    It turns out that I had lots of buttons in Pods that need aria-label, aria-disabled, and aria-pressed info so I went and added those to the next release for Pods 3.0!

    Thanks for your continued efforts at helping all of us raise the bar with accessibility in WordPress and our projects.

    Thread Starter Amber Hinds

    (@alh0319)

    @bordoni thank you so much for taking the feedback seriously and for prioritizing accessibility! It means a lot to a lot of people. If you have beta site you want me to test before release, let me know. We have a client who is paying for remediation and using TEC so I have time dedicated to it. 😊

    @sc0ttkclark, that’s so awesome! I’m glad you find the posts helpful and can use the information to improve your plugin!! ❤️

    Plugin Support Gladys

    (@greventscalendar)

    Hi there,
     
    With our latest release of The Events Calendar 6.2.1 we have made the following accessibility improvements!

    • Fix #1: tabindex=”0″ is removed from the element with class tribe-events-c-subscribe-dropdown__button :check_mark:
    • Fix #2 aria-expanded is applied to the dropdown and changes value from false to true when expanded

    We recommend that you update both plugins to the latest released versions.
     
    As always, we suggest testing updates on a staging site first and having a recent backup, but it should all be smooth sailing. You can remove any workarounds after updating the plugins if you implemented them.
     
    If you still have issues after updating to the latest releases, please open a new support case and include any specific details.
     
    Have a great day,
    Gladys

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Accessibility Issues with the Add to Calendar buttons on event singles’ is closed to new replies.