Frontend-Jessie

[iamseye]

Summary

This is an app that only contains a custom Modal with web accessibility.

Main features: (Demo in the video too, if you want to skip this part)

• The component would pop up after clicking the open modal button
• When the modal opens, should focus on the Confirm button ( first focusable element)
• User can use keyboard Tab to move to next element (Cancel & cross button)
• Click the confirm button, which will pop out the second layer of the modal
• When the user key presses to close the second layer, the focus will be back to the confirm button
• when the user key press the cancel button, the focus will be back to the page's open modal button
• When the user presses the Esc key, the modal should close

Demo

https://www.loom.com/share/c6ea9737128a42f8b155e6bac67b304b

Implementation process

The following steps were taken to work on the app:

• Prioritized tasks & research web accessibility
• Setup up some test requirements.
• Implement a simple modal and add scroll-locking for the modal
• Added React portal for the modal
• Implement the user keyboard navigation and focus actions with hooks
• UI adjustments
• Change colour ratios, using Pika to make sure the colour contrast ratio is greater than 4.5
• Adding a second layer of the modal and fixing focus management bugs
• Tests, and cleanup
• Documentation

How to setup

1. git clone git@github.com:iamseye/contra-assessment.git
2. cd contra-assessment
3. yarn dev

Running tests

yarn test

Decisions and tradeoffs

Dynamic React portal

React portal is designed to create another DOM on the same layer of the app DOM. But instead of having another <div id="modal"/> in HTML. I created a ReactPortal component to dynamic and added the <div /> when the modal opened. Remove it when the modal is close to avoid redundancy.

Opening multiple modals

Open multiple modals are not recommended based on the UX perspective. It can lead to confusion for the user, especially if there are multiple layers of modals. It may also cause clutter on the screen, making it difficult for the user to focus on the primary task. If needed in the real situation, I would prefer to close the first modal before opening the second modal instead of having multiple layers.

But in this case, there's a stacking modal requirement, so the second modal is opening on top of the first modal.

Modal props

It may seem props isOpen and handleClose functions can be not necessary. but

• Check isOpen before rendering the modal can avoid rendering non-used hooks in the component.
  ex:

 {isOpen && (
        <Modal handleClose={handleClose} isOpen={isOpen} name="Confirm">
       ...
       </Modal>)
 }
 
 const Modal = ({ children, handleClose, isOpen, name }: ModalProps) => {
     useEscapeKey(handleClose);  // can avoid render if `isOpen` is false
     .....
 });

• handleClose can props custom actions but not only close the modal.

Modal management

I was considering having a ModalContext to centralize the modal management. If it's necessary to have more than 3 layers of modals, it can lead to having too much logic just to control the isOpen & trigger elements. But using a centralized context approach also means every time added or remove modal needs to rerender all the models, and also needs to keep tracking the orders. I didn't do it this time, considering if we do have context management, should also have maximize 3 layers of the modals to warn the devs from the UX perspective.

If it was a bigger project that I think I can improve further

1. The EscapeKey hooks currently hooks every open modal, improve it to track individual modals.
2. Having more custom web accessibility semantic descriptions for the modals and focusable elements.
3. Increase test coverage for edge cases
4. styled-componented the modal for different project usages

Something else

I'm having the same issue while using esling-config-canonical, I haven't got time to look into it. but some of my linters may not be 100% followed.