GitHub 저장소 개요에 ACCESSIBILITY.md 접근성 선언문이 표시된다
GitHub 블로그 글에 따르면 ACCESSIBILITY.md 파일이 이제 저장소 개요 페이지에 표시됩니다. 프로젝트의 접근성 목표, 기여자에게 기대하는 사항, 지원 환경, 알려진 한계, 장벽 신고 절차를 꾸준히 안내할 수 있는 자리가 한곳에 생긴 셈입니다.
파일을 두는 위치와 조직 단위 상속
GitHub는 저장소 루트, .github/ 디렉터리, docs/ 디렉터리 중 한 곳에 있는 ACCESSIBILITY.md 파일을 인식합니다. 인식된 파일은 저장소 개요 페이지에 표시됩니다. 따라서 접근성 정보를 이슈 트래커나 다른 문서에 흩어 두지 않고 개요 페이지에서 볼 수 있는 파일 하나로 모을 수 있습니다.
저장소마다 파일을 따로 만들지 않아도 됩니다. 저장소는 조직의 .github/ 저장소에서 접근성 선언문을 상속받을 수도 있습니다. 조직 차원에서 공통 선언문을 관리하려는 경우 검토해 볼 만한 방법입니다.
이와 별도로, 새 저장소에는 accessibility 이슈 라벨이 기본으로 포함됩니다. 선언문 파일을 인식하는 기능과 이슈 라벨은 서로 다른 기능입니다. 파일은 위 세 위치나 조직 상속을 기준으로 인식되고, 라벨은 새 저장소에 기본으로 포함됩니다.
Community Standards에서 시작하기
공개 저장소의 메인테이너는 Insights > Community Standards에서 접근성 선언문을 추가하거나 제안할 수 있습니다. 이때 간결한 시작용 문서가 제공됩니다. 글은 이 경로를 공개 저장소 기준으로 설명합니다.
시작용 문서는 짧은 템플릿 형태입니다. 각 항목에 들어 있는 안내 문구를 프로젝트의 실제 정보로 바꿔 넣는 방식입니다. 더 자세한 예시가 필요하다면 Open Source Accessibility Toolkit이 상세한 공개 예시를 제공합니다. 짧은 템플릿으로 시작할지, 자세한 예시를 참고할지는 프로젝트 상황에 맞춰 고르면 됩니다.
형식 부담도 크지 않습니다. ACCESSIBILITY.md 파일에는 정해진 단일 형식이 없습니다. 예시나 템플릿을 그대로 따라야 하는 것이 아니라, 자기 프로젝트에 맞게 고쳐 쓰는 출발점으로 삼으면 됩니다.
실제 선언문이 다루는 내용
GitHub CLI의 접근성 선언문은 표 출력이 스크린 리더로 따라가기 어려운 이유를 설명하고 대안 명령을 함께 안내합니다. 이 명령은 pull request 번호와 제목을 한 줄에 하나씩 출력합니다. 문제가 생기는 상황을 설명하면서 바로 쓸 수 있는 우회 방법까지 담은 사례입니다.
GitHub Annotation Toolkit의 선언문은 검증 범위를 분명히 밝힙니다. 이 선언문은 해당 Figma 라이브러리가 키보드 전용 테스트나 스크린 리더 테스트를 거치지 않았다고 명시합니다.
두 사례는 성격이 다릅니다. 하나는 알려진 장벽에 대한 구체적인 우회 방법을 안내하고, 다른 하나는 아직 테스트하지 않은 범위를 숨기지 않고 밝힙니다. 선언문이 '접근성을 지원한다'는 선언에 그치지 않고, 현재 상태와 한계를 함께 적는 문서가 될 수 있음을 보여 줍니다.
신고 경로와 WCAG 표현에서 주의할 점
장벽 신고 경로는 장애 사실 공개, 스크린샷, 녹화를 요구하지 않아야 한다고 권장됩니다. 신고하는 사람에게 이런 자료를 필수로 요구하면 신고 자체가 어려워질 수 있으므로, 신고 방법을 적을 때 이 부분을 먼저 확인하는 것이 좋습니다.
WCAG 관련 표현도 구분해서 써야 합니다. WCAG 버전과 수준을 목표로 적는 것은 검증된 준수를 뜻하지 않습니다. 준수를 주장하려면 평가가 필요하고, 그 평가의 범위, 날짜, 방법, 평가자를 밝혀야 합니다.
그래서 선언문에서는 '목표'와 '준수'를 섞어 쓰지 않는 것이 중요합니다. 평가를 거치지 않았다면 목표로만 적고, 준수를 언급한다면 평가 정보를 함께 밝혀야 합니다.
공개 저장소라면 Insights > Community Standards의 시작용 템플릿으로 초안을 만들고, 더 자세한 구성이 필요할 때 Open Source Accessibility Toolkit의 예시를 참고해 프로젝트에 맞게 다듬어 볼 수 있습니다.
