#aria
노트 8개
Frontend
Accessibility장애가 있는 사람도 웹을 인지하고 조작하고 이해할 수 있게 만드는 일. 장애는 능력과 환경의 불일치이고, 브라우저는 시맨틱 HTML로 접근성 트리를 만들어 보조 기술에 넘기며, WCAG가 최소선을 정한다. 표준을 지켜도 쓰기 어려울 수 있어 장애인과의 사용성 테스트와 조직 차원의 우선순위가 필요하다. 사용자 관점과 WCAG, 시맨틱 구조·대체 텍스트·폼·ARIA·키보드·위젯·CSS 기법, 자동·수동 평가와 스크린 리더 테스트를 하위 노트로 잇는다.
Frontend › Accessibility
복합 위젯의 ARIA 패턴: 콤보박스·날짜 선택기·메뉴·상태 알림네이티브 요소가 없는 복합 위젯을 스크린 리더가 이해하고 조작할 수 있게 만드는 패턴. 자동완성 콤보박스, 날짜 선택기(grid)와 날짜 직접 입력, 사이트 메뉴와 menubar의 구분, 수량 조절 버튼, 정렬 표, 페이지 번호, 툴팁, 좌석 배치 같은 2차원 선택, 그리고 로딩·토스트·글자 수·실시간 검증 같은 상태 알림을 정리한다.
Frontend › Accessibility
스크린 리더로 테스트하기스크린 리더 테스트는 읽는 순서, 대체 텍스트, 제목·랜드마크·폼·표의 의미가 실제로 어떻게 들리는지 확인한다. 데스크톱은 NVDA나 JAWS 하나에 VoiceOver를, 모바일은 iOS VoiceOver와 Android TalkBack을 쓰고, 각 스크린 리더의 최소 단축키(읽기 시작·중지, 제목·랜드마크·폼 이동, 요소 목록)만 익히면 기본 점검이 된다.
Frontend › Accessibility
접근 가능한 위젯: 펼침·탭·캐러셀펼침(디스클로저)·아코디언은 <details>/<summary>와 name 속성으로 먼저 만들고, 직접 만들면 button + aria-expanded + hidden을 쓴다. 탭은 APG 패턴대로 tablist·tab·tabpanel과 로빙 tabindex, 방향키를 갖추고, 캐러셀은 정지 버튼·포커스 시 정지·숨은 슬라이드 차단·라이브 영역을 갖춘다.
Frontend › Accessibility
접근 가능한 페이지 구조스크린 리더·키보드 사용자는 페이지를 위에서부터 읽지 않고 제목·랜드마크·링크 목록으로 건너뛰며 탐색한다. 페이지 제목, 문서 언어, 제목 계층, 영역, 목록, 건너뛰기 링크, 사이트 검색, iframe 제목, 데이터 표의 머리글 연결이 그 탐색 경로를 만든다.
Frontend › Accessibility
접근 가능한 폼과 오류 처리모든 입력 칸에는 코드로 연결된 이름이 있어야 한다. label을 기본으로, 표처럼 일대일이 안 되는 곳은 aria-labelledby, 보조 설명은 aria-describedby로 잇고, 묶음은 fieldset·legend로 준다. 검증은 서버와 클라이언트를 함께 두고, 오류는 알리고·데려가고·다시 제출하게 하는 세 단계로 복구시킨다. WCAG 2.2의 중복 입력 금지와 인지 테스트 없는 인증까지 다룬다.
Frontend › Accessibility
ARIA와 접근 가능한 이름ARIA는 HTML로 표현할 수 없는 role·state·property를 접근성 트리에 더하지만 동작은 더하지 않는다. 다섯 가지 사용 규칙, 접근 가능한 이름과 설명이 계산되는 순서(aria-labelledby > aria-label > 네이티브 label·alt > 내용 > title > placeholder), Label in Name, 라이브 영역을 정리한다.
Frontend › Accessibility
WCAG와 POUR 원칙WCAG는 인지·운용·이해·견고(POUR) 네 원칙 아래 13개 지침과 성공 기준으로 웹 콘텐츠 접근성의 최소선을 정한다. 2026년 기준 권고안은 WCAG 2.2(86개 기준, 4.1.1 삭제)이고 따로 요구되는 기준이 없으면 AA를 목표로 한다. 형제 지침(ATAG·UAAG)과 각국 법, 원칙별 점검 질문, 모든 성공 기준의 체크리스트를 정리했다.