자동 접근성 점수로 웹사이트의 접근성을 증명할 수 있을까요?

업체가 높은 접근성 점수를 보여주며 작업을 승인해 달라고 한다면, 점수만으로는 충분하지 않습니다. 그 점수는 검사한 콘텐츠에 자동화된 규칙을 적용한 결과를 보여줍니다. 무엇을 테스트했는지, 사람이 무엇을 확인했는지, 아직 남은 일이 무엇인지 알아야 합니다.

자동 검사는 유용합니다. 장벽을 찾아내고 수정이 제대로 되었는지 확인하는 데 도움을 줍니다. 문제는 이러한 검사 결과를 웹사이트 전체에 대한 결론으로 받아들일 때 생깁니다.

점수에는 실제로 무엇이 반영되나요?

구체적인 예로 Lighthouse를 살펴보겠습니다. Lighthouse의 접근성 점수는 검사 항목마다 가중치를 달리 두고 통과 여부를 반영하는 방식으로 계산됩니다. 항목마다 점수에 미치는 영향이 다릅니다. 수동 검사는 점수에 포함되지 않으며, 영향이 낮거나 모범 사례에 해당하는 일부 검사도 점수에 반영되지 않습니다. 이는 Lighthouse의 계산 방식이며, 다른 도구는 다르게 작동할 수 있습니다.

따라서 Lighthouse 점수가 높다는 것은 테스트한 콘텐츠가 해당 결과에 포함된 자동 검사 항목에서 어떻게 평가되었는지를 보여줍니다. 수동 검사를 통과했다는 뜻은 아닙니다. 검사하지 않은 페이지나 인터페이스 상태에서 어떤 일이 일어나는지도 알려주지 않습니다.

더 넓은 결론을 내리기 전에 어떤 도구와 버전을 사용했는지, 어떤 페이지를 검사했는지, 각 페이지의 어떤 상태를 포함했는지 물어보세요. 문의 양식은 제출 전, 오류가 표시된 후, 제출이 성공한 후에 확인할 사항이 서로 다릅니다.

평가 도구 선택에 관한 W3C 지침은 도구마다 검사 범위가 다르며 접근성의 모든 측면을 자동으로 검사할 수는 없다고 설명합니다. 사람의 판단도 필요합니다. 유용한 보고서라면 발견 사항과 함께 이러한 한계도 보여줍니다.

문의 양식을 보면 확인할 질문이 어떻게 달라지는지 알 수 있습니다

“참조 번호”라고 표시된 입력란이 있는 문의 양식을 가정해 보세요. 특정 웹사이트에서 발견된 문제가 아니라 가상의 예입니다. 자동 검사는 입력란에 레이블이 있는지 확인할 수 있습니다. 하지만 “참조 번호”가 무엇을 입력해야 하는지 알려주는지는 사람이 판단해야 합니다. 주문 번호일까요, 고객 번호일까요, 아니면 다른 정보일까요?

이제 누군가 필수 입력란을 비워 둔다고 가정해 보겠습니다. 승인된 테스트 환경에서 가상의 정보를 사용해 오류를 표시합니다. 메시지는 무엇이 누락되었는지 알려주나요? 키보드를 사용하는 사람은 입력란으로 이동해 내용을 고치고 제출 버튼까지 갈 수 있나요? 관련 화면 읽기 프로그램 설정에서 오류를 찾고 이해할 수 있나요?

수정한 뒤에는 확인 메시지도 살펴보세요. 메시지가 전송되었는지, 추가 조치가 필요한지 알 수 있나요? 실제 문의가 전송되지 않도록 합의된 환경에서 테스트하세요. 이런 점을 보여주기 위해 개인 정보를 공개 스캔 서비스에 올릴 필요는 없습니다.

핵심은 증거가 어떤 상태와 동작을 다루는지입니다. 아무 작업도 하지 않은 양식을 스캔했다면 오류와 확인 상태도 검사하지 않는 한 해당 상태까지 확인된 것은 아닙니다. 이러한 상태를 검사 범위에 넣으면 도구가 일부 항목 확인에 도움을 줄 수 있습니다. 모든 스캐너가 이런 상태를 다루거나 놓친다고 단정하지 말고 실제로 무엇을 실행했는지 물어보세요.

서로 다른 세 가지 답을 구분하세요

어떤 자동 검사를 통과했나요? 도구 결과는 실제로 검사한 콘텐츠와 상태에 대해 이 질문에 답할 수 있습니다. 수정하고 다시 검사해야 하는 실패 항목도 확인할 수 있습니다.

사람들이 중요한 작업을 완료할 수 있나요? 지식이 있는 사람의 수동 평가, 관련 입력 방식과 보조 기술을 사용한 검사, 장애인 참여를 통해 더 많은 장벽을 찾을 수 있습니다. 확인한 작업, 페이지, 상태와 사용 환경을 기록하세요. 한 가지 환경에서 성공해도 다른 환경은 여전히 확인되지 않은 상태입니다.

사용자 참여에 관한 W3C 지침은 사용자의 경험이 접근성 표준에 따른 평가를 보완한다고 설명합니다. 몇 차례의 사용자 테스트가 성공해도 모든 사람이 웹사이트를 이용할 수 있다는 뜻은 아닙니다. 수동 평가에도 범위가 있습니다. “직접 확인했다”는 말만으로는 부족하며 무엇을 확인했는지 설명해야 합니다.

정의된 웹사이트 범위가 선택한 표준을 충족하나요? 이 질문에는 해당 표준에 따른 평가가 필요합니다. 적합성 평가에 관한 W3C 지침은 범위를 정하고, 대표 표본을 선택하고, 평가한 뒤 보고하는 방법을 설명합니다. 보고서에는 무엇을 다뤘는지, 어떤 발견을 바탕으로 결론을 내렸는지 밝혀야 합니다. 점수나 양식 제출 성공만으로는 이 질문에 답할 수 없습니다.

실제로 도움이 되는 보고서를 요청하세요

테스트 도구를 직접 다룰 필요는 없습니다. 무엇을 승인하는지 판단할 수 있을 만큼은 알아야 합니다. 업체에 다음 내용을 간단히 정리해 달라고 요청하세요.

• 사용한 도구와 버전, 테스트한 페이지와 인터페이스 상태, 포함된 자동 규칙.
• 발견한 장벽과 영향을 받는 작업. 예를 들면 오류 수정이나 문의 전송.
• 수정한 내용과 재검사 결과.
• 수행한 수동 평가와 보조 기술 검사, 그 범위와 사용 환경.
• 테스트하지 않았거나 해결되지 않은 사항, 그리고 추가 평가를 맡을 사람.

이런 기록을 남기는 실례로, 영국 노동연금부의 테스트 지침은 자동 검사, 수동 검사, 보조 기술 검사를 함께 사용하고 테스트 기록을 보관하는 부처의 방식을 설명합니다. 이는 해당 부처의 운영 방식이며 모든 웹사이트에 요구되는 고정된 패키지는 아닙니다.

기록된 수정 사항은 승인하면서도 웹사이트 전반의 접근성 문제는 계속 확인할 수 있습니다. 예를 들어 테스트한 양식의 레이블 수정은 재검사 결과를 근거로 승인할 수 있지만, 오류와 확인 상태에 대한 평가는 여전히 남아 있을 수 있습니다. 남은 작업을 적고 담당자를 정하세요.

그러면 다음 결정을 내리는 데 도움이 됩니다. 이미 알려진 장벽을 수정하고 필요한 추가 평가를 마련하세요. 더 높은 점수는 무엇을 검사했고 웹사이트를 이용하는 사람에게 어떤 변화가 생겼는지 함께 볼 때 의미가 있습니다.