시작하며

이번에는, 이슈 처리 과정 중 있던, Focus Trap 문제인 줄 알았으나 다른 어이없는 것이 원인이었던 사건을 간단하게 이야기 해보려고 한다.

이 후 Focus Trap에 대해서 조금 알아보며 정리했던 것들도 있기 때문에 글을 작성하게 되었다.

이슈 해결기

상황을 설명하자면..

서비스에 바텀 탭바가 존재했다.

시연 과정에서 파악한 이슈인데, 특정 페이지에서 바텀 탭바를 클릭해 해당 페이지로 이동하는 과정에서 발생했다.

컨텐츠 화면을 클릭 후 바텀 탭바를 클릭해야 링크로 이동되었던 것이다.

마치 포커스를 다른 영역에 주어 이동시키고 바텀 탭바를 클릭할 때 동작하는 것으로 보였기 때문에 포커스 트랩을 원인으로 추측하고 확인해보았다.

결론

갑작스럽지만, 결론부터 말하겠다.

바텀 탭바 위에 있던 바텀시트에 있는 after가 바텀 탭바를 가려서 클릭되지 않았던 것이었다.

바텀 시트 높이를 조금 올린 후 테스트를 진행 시 정상 작동함을 확인했기 때문에 확실해 보인다.

이에, 해당 after영역에 point-events:none처리를 통해 해결했다.

Focus Trap

직접 코드를 뜯어 after부분을 발견하기 전, Focus Trap이 적용된 방식을 보며 이를 알아보았다.

Motimo는 바텀시트를 위해 Vaul 라이브러리를 사용하고 있는데, 이 라이브러리는 Radix를 기반으로 하는지, span의 data-radix-focus-guard라는 속성 명을 갖는 가드를 사용하여 Focus Trap을 적용하고 있다.

이 방식은 Top-FocusGuard와 Bottom-FocusGuard를 두어 tab및 shft+tab으로 포커스 이동 시 해당 이들로 둘러쌓인 범위 안에서 포커스가 이동하도록 만든다고 한다.

보다 기본적인 방식으로는, Focus Trap적용 영역에서 tab 등의 동작에 대해, 이동할 컴포넌트를 지정해주는 방식이 있다.

마치며

Focus Trap에 대해 자세히 공부하지 않고, 방법론만 알아봤기 때문에 글이 짧다.

사실 이 경험을 통해 접근성 기술들에 대해 처음으로 고민해봤기 때문에 꽤 인상 깊었다.

이외에도 많은 접근성 기술들이 있는 것을 알게 되었는데, 사실 이 분야도 깊이 들어가면 한 없이 깊어질 수 있다는 것을 느꼈다.

접근성 관련 조항 등을 숙지하고, 기술적으로 해결하며 이를 검증하는데는 많은 전문성이 필요한 것이다.

토스도 접근성 기술자를 따로 채용하는 등의 행보를 보인 것으로 보아 위를 확실히 알 수 있었다.

사실상 일반적인 웹 개발자의 경우는 Radix 등의 headless 컴포넌트를 사용한다거나, 내부 규칙에 맞게 처리하는 등으로 해결할 것이기에 깊이 공부할 기회가 없기도 하겠지만, 활용도 있어보이는 기술들도 있기 때문에 기회가 된다면 공부하고자 한다.