웹 접근성 공부를 위해서 공부한 내용 시리즈
▶ 2024.02.17 - [Web] - 웹 표준, 웹 호환성, 웹 접근성
▶ 2024.02.21 - [Web] - 웹 접근성 시나리오
▶ 2024.02.25 - [Web] - 웹 접근성이 왜 필요할까?
▶ 2024.03.16 - [Web] - 웹 접근성 기술 학습
▶ 2024.03.20 - [Web] - 웹 접근성 시나리오 - 2
▶ 2024.03.27 - [Web] - WAI-aria
▶ 2024.03.31 - [Web] - 웹 접근성 시나리오 - 3 <= 현재 글
▶ 2024.04.04 - [Web] - 사용자가 입력하는 이미지
웹 접근성 시나리오 - 오류 식별
사용자들이 형식에 맞지 않는 입력을 했을 때, 이를 식별하고 정정할 수 있는 방식으로 자주 사용한다.
이때 확인 버튼을 누르면 어떻게 이동이 되어야 할까?
이름이 입력이 안되었기 때문에 이름 입력창으로 포커스를 이동시키면 된다.
다음으로 내부 코드가 아래와 같다면 어떤 추가적인 오류가 발생할 수 있을까 :
<li>
<label>아이디</label>
<input type="text" id="userId" name="userId" maxlength="20" />
</li>스크린리더로 읽을 시 "편집창"으로만 읽히기 때문에 사용자는 어떤 편집창인지 알 수 없다.
결국 사용자는 이전 태그로 돌아가서 읽어보고 다시 돌아와야 하는 불편함이 존재한다.
해결하기 위해서는 label 태그를 수정하면 간단하게 처리할 수 있다 :
<li>
<label for="userId">아이디</label>
<input type="text" id="userId" name="userId" maxlength="20" />
</li>label 태그의 for 속성을 사용해서 연결하면 읽을 시 "아이디 편집창" 이라고 읽는다.
또 다음과 같이 오류 시 입력창 아래에 오류 문구가 나오는 경우가 있다.
오류 문구가 나오는 것이 뭐가 문제인지 알 수 없는 사람도 있겠지만 디자인 상으로 안이쁘고, 화면이 번잡해질 수 있다.
일차적인 해결 방법으로 input의 placeholder 속성을 사용할 수 있다.
하지만 placeholder는 색상이 연해서 대비가 낮고, 텍스트를 입력하면 내용이 사라진다.
또, placeholder 속성의 경우 browser fallback이며, 웹 접근성 관점에서 권장되지 않는다.
※ browser fallback ?
fallback은 대비책을 뜻한다. 즉, browser fallback은 브라우저의 대비책이다.
웹 접근성 관점에서 browser fallback은 title, placeholder, required 속성 등이 있다.
이들은 스크린리더에 따라 읽어주는 스크린리더도 있고, 읽기를 지원하지 않는 스크린리더도 있다.
또한 읽어 주더라도 순위가 최하위에 위치함으로 어떻게 읽히게 될지 예측하기가 어렵다.
이런 측면에서 browser fallback은 지양해야 한다.
그렇기 때문에 aria-label을 추가적으로 사용해야 한다.
즉, placeholder를 사용하면 aria-label도 추가적으로 사용을 해야한다.
추가적으로 요즘은 실시간으로 규칙에 맞지 않으면 오류가 나오는 경우가 있다.
이때 스크린리더는 이미 다른 곳을 읽고 있다면 사용자는 어떻게 알 수 있을까?
쿠팡의 경우 aria-live라는 속성을 사용하고 있다.
aria-live 속성은 실시간으로 내용을 갱신하는 영역에 쓰일 수 있으며 aria-live 속성에 들어갈 수 있는
값에는 polite, assertive 가 있다.
polite를 사용하는 경우 중요도가 낮은 내용으로 간주해서 스크린리더가 현재 읽는 것을 끝내면 뒤늦게 전달한다.
assertive를 넣는 경우에는 중요도가 높은 내용으로 간주하여 진행중인 보조기기 작업을 중단하고 즉시 전달한다.
웹 접근성 시나리오 - 로딩 처리
우리가 은행을 사용하면 항상 만나게 되는 컴포넌트인 로딩 컴포넌트이다.
로딩 컴포넌트는 말 그대로 페이지의 렌더링 혹은 페이지의 처리를 위해 화면에 나타나는 웹 컴포넌트이다.
이러한 로딩이 사용자로써 화는 나지만 어떤 문제가 있을까? 관련 내용이 해당 [링크]에 있다
0.1초 이하의 로딩
0.1초 이내에 콘텐츠를 로드하는 데 성공하면 즉각적인 것으로 간주되어 사용자에게 눈에 띄지 않는다.
이 경우에는 굳이 로딩 화면을 노출할 필요가 없다.
0.1~1초 사이
온라인 소프트웨어에서도 예상되는 현상이며 사용자에게 눈에 띄지 않는다.
이때도 스피너나 애니메이션으로 " 그 시간을 채우려고" 할 필요가 없다. 오히려 사용자가 더 혼란스러워질 수 있다.
1초 이상
1초를 넘어가면 사용자는 대기 시간을 인지하게 된다. 이때 부터는 스피너나 블러처리 등 다양한 방법으로
로딩을 표시해줄 수 있다.
10초 이상
대규모 작업의 경우 사용자에게 얼마나 수행되었는지 명확한 가시성과 시스템이 계속 작동한다는 사실을
알려주는 기능이 필요하다.
※ 근데 은행 로딩창은 왜 나오는거지 ?
근데 우리가 은행을 이용할 때 특별한 작업을 하는게 없다. 그저 로그인 화면을 가면 로딩창이 나오면서 일정 시간을
기다려야하는 문제가 있다.
왜 사용자는 아무것도 하지 않았는데 기다려야 할까?
은행은 보안적인 이유로 로딩창이 나타난다. 로딩이 끝나면 보안 프로그램을 설치하라고 하는 화면이 나오는데
프로그램이 제대로 설치되어 있는지 검증하기 위해서 로딩을 하는 것이다.
보안 프로그램이 설치가 되었는지 사용자의 컴퓨터 특정 포트로 접근해서 응답을 받는데 걸리는 최대의 시간을
은행사마다 정해서 그 시간동안 응답이 오는지 대기를 하는 시간 동안 로딩 화면이 노출되는 것이다.
'Web' 카테고리의 다른 글
| 구글 SEO (1) | 2024.04.06 |
|---|---|
| 사용자가 입력하는 이미지 (0) | 2024.04.04 |
| WAI-aria (0) | 2024.03.27 |
| 랜드마크 롤 (0) | 2024.03.24 |
| 웹 접근성 시나리오 - 2 (0) | 2024.03.20 |
