ReactFoo Delhi

On React, performance and front-end engineering

Building Accessible React apps

Submitted by Vikas Parashar (@vicodin) via Zainab Bawa (@zainabbawa) on Oct 10, 2019

Duration: 40 mins full talk Status: Confirmed & Scheduled


As web developers, we all have a responsibility to develop accessible sites/apps, but for most of us it’s another checkbox to tick. This talk will be about how accessibility and good user experience goes hand in hand, and are not mutually exclusive.

In this talk, we will talk about what is accessibility and how we raised awareness about it in HackerRank. We will talk about the process to integrate accessibility first mindset and various ways in which we improved accessibility and ingrained it in our development process which helped the company grow.

Key takeaways from case study:

  • Why should we care about accessibility.
  • How to improve accessibility of react apps.
  • How to use test react apps for accessibility(Resources)
    • Unit testing
    • Browser testing
    • Keyboard testing
    • Screen reader testing
    • Linters in code editor


  1. What is accessibility

    1. General accessibility
    2. Web accessibility
  2. Why we did it(Making HackerRank websites accessible)

    1. Business reasons
      1. UX improvement
      2. Inclusion/Increase in user base(more people can user our site)
      3. Corporate Social Responsibility
      4. More enterprise customer(some customer requires product accessibility compliance in contract)
    2. Legal reasons(accessibility compliance laws in various countries, latest Apple and Dominos fiasco)
    3. Others(Empathy, WCAG, ATAG)
  3. How we did it

    1. Updating existing reusable UI components(will have examples of few major components with code and demo)
    2. Custom components specific to accessibility(HOC to detect keyboard navigation with code and demo)
    3. Showing minimum contrast pass/fail on internal colour library(code and demo)
    4. Setting up Unit testing(code and examples)
    5. Setting up Dev tools warning(code and demo)
    6. Dark mode.(Strategy/code and demo, and screenshots of feature requests from visually impaired users)
    7. eslint-plugin-jsx-a11y to catch issues while coding(screenshots/demo)
    8. ChromeVox/VoiceOver for screen reader testing(demo)
  4. What’s next/We’re still doing it

    1. Accessibility is a process and not a project.
    2. Integrating reach router functionality with react router 5
    3. CI/CD integration.
  5. Impact

    1. Positive and exciting feedback from users on dark mode and on user experience.
    2. As of now, there is no way to track screenreader users or distinguish different users with disabilities from the rest.
    3. Idea of web accessibility is to remove discrimination from web and any attempt towards that helps the cause.
    4. Levelling the field for candidates as now they don’t need to disclose their disability and ask for special treatment. We are closer to make our site accessible for everyone which removes the dependency from customer support team.



Speaker bio

Vikas Parashar is frontend engineer and web accessibility evangelist at HackerRank. He has also co-organised InOut hackathons in the past.




  • Raghavendra Satish Peri (@artofvision) 7 months ago

    Hello Vikas,
    Here are some comments,

    Updating existing reusable UI components(will have examples of few major components with code and demo)
    Raghava: can we know what are these components? Are they menus, tab pannels, tree widgets?
    1. Custom components specific to accessibility(HOC to detect keyboard navigation with code and demo)
    Raghava: Did not understand what you meant by custom commponents specific to accessibility? Can you expand on this?

    Chrome vox is not a recommended screen reader to test for web accessibility bugs. NVDA, JAWS & Voiceover are preferred. Here is a data on which screen readers & browsers need to be used for accessibility testing

    any automation tools used like react axe?
    eslint-plugin-jsx-a11y can help you easily pinpoint any accessibility issues in your JSX, but it does not test any of the final HTML output. react-axe is a library that does exactly this by providing a React wrapper around the axe-core testing tool by Deque Labs.

    Did you use WAI-ARIA to update the components & make them accessible? If yes what are the challenges faced?

    • Vikas Parashar (@vicodin) 7 months ago

      Hey Raghavendra!

      Some components which I have in mind are following:

      Input: Basic fixes like passing label as prop, fallback is explicit label is not provided.
      Button: Single component which can be used for as button or link based on prop but looks visually same.
      Modal/Dialog: Focus trapping, WAI-ARIA attributes, close button accessible by keyboard.
      Dropdown: Usable with up/down keys. WAI-ARIA attributes, closable by ESC key.
      Tab: proper WAI-ARIA attributes, accessible by TAB key.
      ClickableDiv: Custom component for cases where a large section is needed to act like a button. role, tabIndex, keyPress etc added.
      IconButton: Component for clickable icons, takes btnText prop which is used for aria-label
      Form: custom wrapper on Formik form library to have the functionality of form submit on enter, browser alert on navigation if form is dirty.

      I am not planning to demo all of these components since my primary focus is on How we are doing it.

      Custom Component specific to accessibility, we have written a UIkit root component which can be used as top level component and it adds a class on keyboard navigation, which can be used to style focus state for only keyboard focus and not mouse click.

      I added chromeVox since it’s most easily available on every OS so I found it’s good for beginners to get started. I agree with your comment and I would remove it from the resources list.

      We are using a custom wrapper on axe-core for automated testing, which provides a .accessible() method for assertions and logs the error with suggestions for fixes.

      Regarding WAI-ARIA, We have used and still updating some of the components with suitable attributes.

      Regarding the site that we made accessible, we recently started fixing the accessibility issues and there are lot of work still needs to be done, so it will be unfair to give any link for audit right now. Currently we are focusing mostly on making our UI Library and candidate experience accessible.

      • Raghavendra Satish Peri (@artofvision) 7 months ago

        Hi vikas,
        Can you put your slides here?

        I want you to put the journey this way,
        Custom controls you are making accessible. I know you cannot explain all the widgets so list the widgets & explain 2 widgets during your talk.
        ARIA roles, states & properties used to make these widgets accessible.
        Learning’s of using ARIA. Here explain how ARIA is included in your regular code & show the code.
        Are these widgets tested by any persons with disability?

        • Vikas Parashar (@vicodin) 7 months ago

          Hi Raghavendra,

          I am working on the slides and will upload them soon.

          I have restructured the slides into following sections:

          1. What is Accessibility?
          2. Why should we care?
            - Good for business(UX, SEO, customers, CSR)
            - Legal reasons(different laws)
            - Empathy
          3. How we are doing it?
            - Process of development is design, code and test.
            - Setting up tooling for this process
            1. Color contrast checker in UI library(for design process)
            2. Linter for accessibility rules(for coding) [screenshots of code and editor]
            3. Dev tools logger(for testing in browser) [screenshots of code and demo, video of demo]
            4. Unit tests(for testing) [screenshot of failed test, screenshot or link of code]
            5. Fixing some common UI components
              - Button: Custom component which works like button or link based on props(screenshots of before, after and use case)
              - Dialog: Web dialog, with focus trap, keyboard accessibility, and various ARIA to make it more accessible(screenshot of code and explaination of diffrent ARIA)
          4. What’s next?
            - React router 5
            - CI/CD integration
          5. Conclusion
            - It’s a ongoing process and not something that can be done one time.
            - Impact.
          6. Resources

          I have prepared slides till the end of point 3(How we are doing it?).

          At the moment, we haven’t tested any of these widgets with persons with disabilities but an accessibility audit with user testing is planned for our new candidate experience site which is currently WIP.

        • Vikas Parashar (@vicodin) 7 months ago

          Hey Raghavendra,

          I have updated slide link in the proposal.

          • Raghavendra Satish Peri (@artofvision) 7 months ago

            hi vikas, can you give me access to download the slides as ppt. I am a person with visual impairment & prefer ppt than google slides. it will be easy to run through the content.

            • Vikas Parashar (@vicodin) 7 months ago

              Sorry about that, I have updated the link with the updated permissions.

              • Raghavendra Satish Peri (@artofvision) 7 months ago

                Keyboard accessibility aka Keyboard shortcuts- remove the term keyboard shortcuts.
                raghava: keyboard accessibility is tested with tab key to move forward, shift+tab to move backward, enter & spacebar keys to check the click events. Keyboard shortcuts are provided through accesskeys& screen reader shortcuts are different too.

                Dialog behavior
                when a dialog is opened focus must move to a element in the dialog.
                focus must be trapped inside the dialog. this includes both arrow keys when a screen reader is on & tab key focus too.
                focus must return to the element that triggered the dialog.
                you expanded on ARIa modal & the fallback if aria modal is not used is to use aria-hidden=true on the body tag of the parent page.
                aria-modal needs to be used in conjunction with role=dialog. mention this please.

                People want link to look like a button but act like a link
                raghava-actually links should be links & buttons should be buttons. here is a explanation
                Should not be able to close on ESC key press if using as alert modal(User’s immediate attention is needed)
                raghava: this is not true. alertdialog can always be dismissed with escape key. here is the description from authoring practice

                • Vikas Parashar (@vicodin) 7 months ago

                  Keyboard accessibility aka Keyboard shortcuts- remove the term keyboard shortcuts.
                  - Done.

                  focus must be trapped inside the dialog.
                  - In current implementation, it does go to browser UI(tabs, bookmarks) but on keep tabbing comes back in dialog only. So for web content it’s trapped in dialog but browser is still reachable.

                  you expanded on ARIa modal & the fallback if aria modal is not used is to use aria-hidden=true on the body tag of the parent page.
                  - Shall I include it in slide or explaination during the slide is okay? Also, I guess you mean parent node for the main content and not body because in most cases dialog markup is inserted in body and aria-hidden will remove dialog from the flow too.

                  aria-modal needs to be used in conjunction with role=dialog. mention this please.
                  - I was planning to mention this in talk, will add in slide also.

                  actually links should be links & buttons should be buttons.
                  - This is actually the product requirement since most CTA links do look like button. This line was in context to what we had to do in our company. The fix we introduced made the component semantic and screenreader accessible, though I agree it’s confusing for sighted users. I can remove that point all together.

                  Should not be able to close on ESC key press if using as alert modal(User’s immediate attention is needed).
                  - Thanks. I was not aware of that. I have updated the slides. I would love to have a discussion on this more in terms of product requirement(like when user needs to be blocked until they take an action) and how can we achieve that.

  • Raghavendra Satish Peri (@artofvision) 7 months ago

    Hi Vikas, can i take a look at the site that is made accessible. I will quickly run a A11Y audit & see. I am just curious.

  • Zainab Bawa (@zainabbawa) Proposer 7 months ago

    Thanks for the rehearsal, Vikas. Here is the feedback from today’s rehearsal:

    1. Too much time is taken on explaining why accessibility. This part should not be more than 30 seconds. You can simply state that accessibility is a business, legal and product requirement and move on.
    2. Remove CSR as a reason for implementing accessibility because accessibility is a civil right. CSR makes accessibility become an act of charity. Since the language has changed to civil rights, this part has to be removed.
    3. When you explain ‘what is accessibility’, take the quote from Tim Berners’ Lee and move into the context of your talk.
    4. The takeaways have to be concrete rather than general statements. For example, be empathetic is a general statement. Instead, is a concrete takeaway to do user testing with users who need accessibility most?
    5. What is your approach with ARIA models and role models with the Hackerrank application?
    6. Show before-after demos of the application.
    7. Share your learnings with ARIA. This will be a solid takeaway for the developer audience.
    8. The button and link example was very good. Explain here that a screen reader takes precedence over native HTML. Here, mark on the slides “do this” and “don’t do this” so that participants can understand the dos and don’ts of accessibility.
    9. Choose another example instead of role and role dialogue. Show the tab component example instead.
    10. Add more details in the resources section. Add the W3C laws link in the resources section.
    11. Add a video demo towards the end with the screen reader.

    Submit your revised slides by 29 October latest for review and final rehearsal.

    • Vikas Parashar (@vicodin) 7 months ago

      Hi Zainab, I have updated the slides.

  • Zainab Bawa (@zainabbawa) Proposer 7 months ago

    Thanks for the revised slides, Vikas. These look much tighter and smoother than the previous ediion. Kudos, good work!

  • Raghavendra Satish Peri (@artofvision) 7 months ago

    At hasgeek events we are trying to make our events accessible for people with disabilities. To achieve our goal is to first get the content of presentations accessible. Here is some guidance to make the presentations accessible. Please use these fonts & size so that even able body people can see the content in the auditorium during presentation.

    Fonts and Font Size
    Because they are the easiest to read, only use Sans Serif fonts, such as Arial and Verdana. Since a PowerPoint presentation will most likely be projected onto a large screen consider how far the audience will be from the screen and choose a font size accordingly. The minimum font size for a PowerPoint presentation should be 24 points.

    For more accessibility info on making presentations accessible use the following link

  • Raghavendra Satish Peri (@artofvision) 7 months ago

    Hi vikas,
    Here is the feedback… All the best for your talk,

    1. Remove the slides of aria-controls, role tab, tablist & tabpanel…
    2. Put role tablist, tab & tabpanel in one slide & explain them once you showed the demo.
      1. You don’t have to explain each reference… just let the audience knows that here are some references.

Login to leave a comment