사이트 구조 결정 기록 남기기

해결할 문제와 선택 이유를 연결하는 기록

이 원칙을 메뉴 변경에 적용하면 실제로 어떤 자료를 찾기 어려웠는지부터 남길 수 있습니다. 공개된 화면이나 시험에서 관측한 문제와 아직 시험하지 않은 우려를 구별하는 양식입니다. 예상되는 불편을 실제 독자가 겪은 결과처럼 작성하지 않습니다. 회의, 병원의 합의, 이용자의 발언이 제공되지 않았다면 그런 사실을 채워 넣지 않고 현재 있는 자료만 연결합니다.

선택한 관계를 설명할 때에는 변경 전의 출발 문서와 도착 문서, 변경 후에 제공하려는 관계를 대응시킵니다. 어떤 질문을 먼저 답하고 어느 자료를 보충으로 안내하려는지 기록하는 방법입니다. 메뉴 항목의 삭제나 이동이라는 작업명만 남기면 이후에 그 목적을 재구성해야 할 수 있습니다. 운영 양식의 항목을 제안하는 범위이며 W3C가 병원 메뉴의 특정 양식을 의무화했다는 뜻은 아닙니다.

잘되지 않은 접근도 남기라는 권고는 비슷한 변경을 검토할 때 실패한 이유를 읽을 수 있게 하는 데 활용할 수 있습니다. 대안 자체가 나쁜지, 당시 자료가 부족했는지, 특정 구현 조건에서 작동하지 않았는지를 실제 근거로 구별합니다. 한 상황의 실패를 모든 홈페이지에 적용되는 금지로 확대하지 않습니다. 아직 시도하지 않은 대안에는 실패라는 결과를 붙이지 않습니다.

원문은 구현 경험을 기록할 뿐 아니라 전달할 방법도 고려하라고 안내합니다. 구조 결정의 근거를 찾아야 하는 사람이 자료에 접근할 수 있는지 검토하는 운영 질문에 적용할 수 있습니다. 설명 자료를 어디에서 찾는지와 어떤 결정에 연결되는지가 드러나도록 구성하는 제안입니다. 파일이 존재한다는 사실만으로 경험이 공유되거나 이해됐다고 보고하지 않습니다.

공통 평가 보고서로 변경의 결과를 비교하기

W3C는 평가 결과를 담을 표준 보고서 구조를 사용하라고 권고합니다. 서로 다른 웹사이트와 같은 웹사이트의 여러 버전을 비교할 수 있기 때문이라고 설명합니다. 메뉴 변경 기록에 적용할 때에는 같은 시험 항목과 결과의 위치를 유지하는 방법을 제안합니다. 이전 보고서의 결론을 새 화면에 복사하기보다 실제 변경된 구조에서 무엇을 시험했는지 대응시킵니다.

평가는 디자인과 개발 과정 전체에서, 특히 주요 단계와 반복 작업 시점에 수행하라고 원문은 안내합니다. 주요 페이지, 절차, 독립 구성요소가 마련되는 대로 평가하고 기존 시험 및 품질보증 과정에 반복적으로 통합하라는 설명입니다. 구조 기록에는 평가한 대상이 전체 사이트인지 메뉴 구성요소인지 특정 이동 절차인지 남길 수 있습니다. 부분 시험의 결과로 전체를 평가한 것처럼 표현하지 않습니다.

디자인을 일찍 평가하면 상당한 작업이 진행되기 전에 문제와 잠재적인 문제를 찾을 수 있다고 W3C는 설명합니다. 구조 후보를 비교한 자료에도 이 구별을 적용할 수 있습니다. 아직 실행하지 않은 설계에서 예상되는 문제는 잠재적인 문제로, 실제 구현에서 관측한 접근 문제는 실행 결과로 남기는 방식입니다. 두 자료의 성격이 다르면 같은 결과 칸에 넣지 않습니다.

원문은 페르소나와 사용자 이야기 같은 다른 디자인 자료에도 접근성 고려를 포함할 수 있다고 안내합니다. 구조 결정 기록에는 어떤 이용 과제를 기준으로 후보를 평가했는지 연결할 수 있습니다. 실제 사용자 시험의 응답과 설계를 위한 이용 과제는 다른 자료입니다. 가상의 발언을 인터뷰 결과처럼 보태지 않으며 문제를 이해하는 데 사용한 자료의 종류를 명시합니다.

장애가 있는 사용자의 의견을 평가에 포함하라는 안내와 함께, 팀 구성원에게 시험 과정의 참여를 권장하는 설명도 있습니다. 이를 구조 시험에 적용할 때에는 실제 실시한 평가 자료가 있다면 무엇을 관측했는지 기록하는 범위로 사용합니다. 의견을 받지 않은 상태에서는 평가 계획만 남길 수 있습니다. 특정 병원에서 이미 사용자를 참여시켰다거나 같은 문제를 보고했다는 사실을 만들어 설명하지 않습니다.

W3C는 접근성 문제를 문제 추적 시스템에 등록해 자원이 배정되고 표준 품질보증 주기 안에서 수정되게 하라고 안내합니다. 구조 결정의 문제 항목을 실제 후속 작업에 연결하는 방법을 제안합니다. 문제를 발견한 보고서와 해결 결과는 서로 다른 단계의 자료입니다. 등록된 항목이 어떤 시험의 발견에서 나온 것인지 추적할 수 있어야 후속 결과도 같은 문제와 대응시킬 수 있습니다.

보류의 조건과 후속 우선순위를 근거로 설명하기

W3C는 모든 접근성 목표를 충족해야 하더라도 우선순위를 정하면 더 효과적으로 달성할 수 있다고 설명합니다. 구조 결정에서 일부 작업을 먼저 진행하는 경우에는 처리 순서와 목표의 제외를 구별하는 방법을 적용할 수 있습니다. 높은 영향과 해결하기 쉬운 문제부터 다루라는 안내를 참고하되 실제 영향 자료가 없으면 우선순위의 가정을 드러냅니다.

원문은 접근 가능한 템플릿과 구성요소의 개발을 우선하는 예를 제시합니다. 같은 메뉴 구조를 여러 화면에서 쓰는 변경에서는 공통 구성요소의 문제와 개별 문서의 문제를 구별해 순서를 제안할 수 있습니다. 한 구성요소를 수정한 사실만으로 모든 공개 화면의 반영이 끝났다고 답하지 않습니다. 어느 구현에 적용된 결과인지 실제 자료를 읽어 기록하는 질문입니다.

곧 변경될 예정인 콘텐츠 관리 시스템 같은 도구나 시스템의 문제는 우선순위를 낮추는 예로 안내합니다. 이를 현재 구조의 보류 이유에 적용하려면 변경 계획 자체가 실제 자료로 존재하는지 읽어야 합니다. 막연히 언젠가 교체할 수 있다는 생각을 해결 보류의 확정 근거로 쓰지 않습니다. 새 구현에서 같은 접근 문제를 다시 시험할 필요가 있는지도 후속 조건으로 제안할 수 있습니다.

서로 다른 관점을 우선순위 결정에 참여시키고 상황을 정기적으로 검토하라는 권고도 있습니다. 구조 변경의 순서를 선택한 당시의 근거와 이후에 새로 제공된 조건을 비교하는 질문에 적용할 수 있습니다. 외부나 내부 의견이 실제 제공됐는지, 어떤 판단에 영향을 줬는지 자료로 읽습니다. 참여하지 않은 사람의 동의나 합의 내용을 대신 작성하지 않습니다.

구현의 진전은 웹 콘텐츠 접근성뿐 아니라 절차와 정책, 교육과 지식 공유, 조직의 인식과 태도에 대해서도 추적하라고 원문은 안내합니다. 메뉴 변경의 화면 결과와 그 변경을 지속하는 과정의 준비가 다른 상태일 수 있는 이유입니다. 구조 기록의 공개 화면 평가와 운영 절차의 진행을 별도의 항목으로 분리하는 양식을 제안할 수 있습니다.

성과뿐 아니라 성과 부족도 전달하면 지원 부족이나 체계적인 어려움을 드러낼 수 있다고 W3C는 설명합니다. 후속 구조 결정에서 해결하지 못한 문제를 숨기지 않고 현재 근거로 남기는 운영 방법에 적용합니다. 수정 시도와 실제 해결을 같은 표현으로 보고하지 않습니다. 긍정적인 결과만 모은 목록보다 남은 접근 문제를 읽을 수 있는 평가 자료를 참조하도록 구성할 수 있습니다.

교육은 이해가 높아지고 일상적인 관행이 되면서 초기 투자에 대한 이점을 가져온다고 원문은 설명합니다. 축적한 구조 결정의 교훈은 해당 구현을 다시 다루는 데 필요한 설명 자료로 활용할 수 있습니다. 원문은 기존 인력의 교육뿐 아니라 채용 기준에 접근성 역량을 포함하는 방법도 안내합니다. 이를 실제 인력 배정이나 병원의 교육 시행 사실로 바꾸지 않습니다.

이어서 읽을 주제

정보 글의 검색 진입을 별도로 읽을 때: 블로그 상위노출.

문서의 표현 정보를 검토할 때: 구조화 데이터.