[웹 접근성] carousel/slider와 modal 웹 접근성 개선을 위해 알아둘 팁들

Carousel/Slider 접근성 개선

요약

1. 슬라이더를 <section> 태그로 감싸고 aria-label 로 슬라이더의 시작과 끝을 정확히 알게 한다.

2. 슬라이더 사용 방법에 대한 간단한 설명을 추가한다.

3. 보이지 않는 슬라이더는 CSS 를 사용해 숨긴다. 그리고 래퍼 요소에 aria-hidden=true 속성을 추가하고, 보이지 않는 내부 아이템은 tabindex=-1 을 사용해서 숨긴다.

4. 슬라이드에 <ol> <ul> <li> 과 같은 리스트 마크업은 사용하지 않는다.

5. 슬라이드 래퍼에 role="group" 과 번호가 매겨진 aria-label="슬라이드 1 / 8" 를 사용한다.

6. 이전/다음, 슬라이드 아래 위치 표시 점과 같은 요소에 의미 있는 버튼 요소와 명확한 접근성 이름을 사용한다.

7. 현재 active 슬라이드에 해당하는 점 버튼에 aria-current="true" 를 사용한다.

8. 화살표 키 등 사용자 지정 키보드 컨트롤을 사용하면 안 된다.

9. 자동으로 넘어가는 슬라이드는 피하자.

원문

How to build a more accessible carousel or slider

1. Use the <section> tag (or role="region") with a generic aria-label (like aria-label="hero carousel") for the wrapper element so screen reader users know exactly where the carousel starts and ends in the DOM.

2. Add simple instructions for screen reader users to explain how the carousel is set up and how it works. This isn’t required for WCAG conformance, but until carousels become more standardized, instructions can help screen reader users build up a useful mental model.

3. When a slide is not visible on the screen, it should be hidden from all users either using CSS (like display: none or visibility: hidden), the HTML hidden attribute, or by adding aria-hidden="true" to the slide’s wrapper and tabindex="-1" to all the focusable elements inside it. FYI — that last technique is the most animation-friendly.

4. Avoid using list markup for the slides. Screen readers announce how many list items are in each list, but ignores list items that are hidden. If you are truly hiding the slides that aren’t visible (see previous point), then the number of list items announced to a user won’t match the true number of slides. Also, most screen readers don’t tell users which list item they are currently on, or when they enter or exit one (the next point will cover that!), so this markup isn’t especially useful in this use case.

5. Use role="group" and a numbered aria-label (like aria-label="slide 1 of 8") on the wrapper of each individual slide so screen reader users can easily tell where each slide begins and ends and where they are in the set.

6. Use semantic button elements with clear accessible names for all interactive controls, like the previous/next buttons and slide navigation dots.

7. Use aria-current="true" on the button of the slide dot corresponding to the currently-active slide so that screen reader users are informed.

8. Don’t use custom keyboard controls, like arrow keys for navigation. These just confuse real keyboard users, and are probably going to be missed entirely by screen reader users since they already use their arrow keys for navigating with their virtual cursor.

9. Disable autoplay — nobody actually likes it, and for some users this can be an absolute blocker! If you’re not in a position to say “no”, then you can at least minimize the harm by adding a pause or stop button to meet WCAG 2.2.2. But keep in mind, just because something conforms to WCAG doesn’t mean people will actually enjoy using it!

Modal 접근성 개선

요약

1. 포커스 상태를 명확하게 표시하여 제공한다.

2. 모달창이 열리기 전 마지막으로 active 되었던 요소를 저장한다.

3. 모달창이 열리면 모달창 내부의 첫 번째 active 요소로 포커스를 이동시킨다.

4. 모달창이 열린 상태일 때 모달창 내부에만 포커스가 위치하도록 한다.

5. Esc 키를 눌러 모달창을 닫을 수 있도록 한다.

원문

How To Make Modal Windows Better For Everyone

1. Provide a focus state! This obviously isn’t exclusive to modal windows; many elements lack a proper focus state in some form or another beyond the browser’s basic default one (which may or may not have been cleared by your CSS reset). At the very least, pair the focus state with the hover state you’ve already designed. Really, any item that can be focused should have a focus state.

2. Saving last active element. When a modal window loads, the element that the user last interacted with should be saved. That way, when the modal window closes and the user returns to where they were, the focus on that element will have been maintained. Think of it like a bookmark. Without it, when the user closes the modal, they would be sent back to the beginning of the document, left to find their place. Add the following to your modal’s opening and closing functions to save and reenable the user’s focus.

3. Shifting focus. When the modal loads, focus should shift from the last active element either to the modal window itself or to the first interactive element in the modal, such as an input element. This will make the modal more usable because sighted visitors won’t have to reach for their mouse to click on the first element, and keyboard users won’t have to tab through a bunch of DOM elements to get there.

4. confine the user’s focus to the modal window until it is dismissed. If your modal takes over the full screen, then obscure the contents of the main document for both sighted users and screen reader users. Without this happening, a keyboard user could easily tab their way outside of the modal without realizing it, which could lead to them interacting with the main document before completing whatever the modal window is asking them to do.

5. modals should be easy to dismiss. Standard alert() modal dialogs can be closed by hitting the Escape key, so following suit with our modal would be expected — and a convenience. If your modal has multiple focusable elements, allowing the user to just hit Escape is much better than forcing them to tab through content to get to the “close” button.

Reference

• How to build a more accessible carousel or slider
• How To Make Modal Windows Better For Everyone