스크린 리더 사용자가 페이지 전체를 다시 듣지 않고 새 이야기가 추가된 것을 알 수 있으려면?

행동 뒤에 이야기가 추가되면 먼저 짧게 완료를 알리고, 제목이 명확한 본문 영역에 전체 결과를 넣은 다음, 언제 읽으러 갈지는 사용자가 결정하게 할 수 있습니다. 알림은 “방금 한 조작의 결과가 나왔는가”, 본문은 “구체적으로 무슨 일이 일어났는가”, 초점 정책은 “다음에는 어디서 조작하는가”에 답합니다. 각자 한 가지 역할을 맡아야 한 번의 업데이트로 페이지 전체를 다시 읽는 일을 피할 수 있습니다.

상태 메시지는 초점을 받지 않고도 역할이나 속성을 통해 전달할 수 있습니다. 상태 메시지 설명 참고. 이 근거가 이야기 문단 전체의 자동 낭독을 요구하는 것은 아닙니다. 아래의 역할 표, 문구, 상호작용 순서는 교육용으로 직접 설계한 것이며, 특정 제품의 구현을 설명하지 않습니다.

이 글은 “현재 페이지에 이전 이야기를 남겨 두고, 행동 뒤에 결과를 덧붙이는” 상황만 다룹니다. 예시의 오래된 등대, 등대지기, 조작 과정은 모두 허구입니다. 실제 사용자 사례나 실측 성과, DramaFork의 기존 기능이 아닙니다. 설계의 목표 역시 특정한 스크린 리더 동작을 보장하는 것이 아니라, 결과물을 넘길 때 확인할 수 있는 요구사항을 먼저 정하는 데 있습니다.

결과물을 넘길 때 이야기 노드와 함께 아래 표를 작성합니다. 요구사항에 “스크린 리더 지원”이라고만 적어서는 안 됩니다. 그 말만으로는 새 내용을 무엇이 언제 읽어야 하는지 알 수 없기 때문입니다.

상태 메시지는 구리 상자 안에 무엇이 있는지 반복할 필요가 없습니다. 반면 본문은 그 자체로 완전해야 합니다. 알림을 듣지 못했어도 결과를 찾아 이해할 수 있어야 합니다. 진입점의 이름은 목적지를 알려야 합니다. “보기”나 “여기”는 문맥에서 떨어지면 구별하기 어렵습니다.

초점은 현재 조작 위치이며, 스크린 리더의 읽기 위치는 별도로 확인해야 합니다. 요구사항 충족 여부를 검증할 때 버튼에 초점이 남아 있다는 사실만으로 사용자가 원래 문장부터 계속 들을 수 있다고 단정하면 안 됩니다. 역할 표는 기대하는 동작을 정합니다. 실제 구현에서는 모바일 읽기 제스처, 키보드 조작, 콘텐츠 업데이트가 서로 어떻게 작용하는지 확인해야 합니다.

가상의 장면에서 여행자는 오래된 등대 입구에 서 있습니다. 기존 글에는 이렇게 적혀 있습니다. “등대지기가 구리 상자를 탁자 가장자리로 밀어 놓고, 상자 바닥을 살펴보라는 손짓을 한다.” 사용자는 이를 읽은 뒤 “구리 상자 조사하기”를 실행합니다. 이때 조작은 제출되었지만 결과는 아직 준비되지 않았습니다. 화면은 대기와 완료를 구분해야 하며, 곧바로 “새 단서를 발견했습니다”라고 알려서는 안 됩니다.

결과가 준비되면 기존 글 뒤에 다음 내용을 덧붙입니다.

구리 상자를 조사한 결과

상자 밑에 축축한 근무표 한 장이 깔려 있다. 뒷면에는 “종이 울리기 전에 북문으로 가라”라고 적혀 있다. 등대지기는 종이에 적힌 필체를 알아보지만, 설명은 만난 뒤로 미룬다. 누가 이 말을 남겼는지 당신은 아직 모른다.

선택할 수 있는 행동: 근무표의 필체에 관해 묻기. 구리 상자를 들고 북문으로 가기.

동시에 상태 메시지는 “구리 상자 조사가 완료되었습니다. 새 결과를 읽을 수 있습니다”라고만 알립니다. 조작이 끝났음을 확인하되, 근무표의 내용을 미리 읽지 않습니다. 읽기 진입점에는 표에 있는 전체 이름을 사용하고, 사용자가 선택한 뒤에야 새 제목에서 본문으로 들어가게 합니다.

사용자가 기다리는 동안 등대지기의 앞선 말을 다시 읽고 있다고 가정해 봅시다. 결과가 도착했다고 해서 갑자기 북문으로 가는 선택지로 데려가서는 안 됩니다. 원래 조작 근처에 머물러 있다면 그곳에서 바로 읽기 진입점을 찾을 수도 있습니다. 두 경로는 결국 같은 본문에 도달하므로, 알림용으로 축약한 이야기를 따로 저장할 필요가 없습니다.

후속 행동은 이 대목의 끝에 두어 결과를 다 읽은 사용자가 순서대로 도달할 수 있게 합니다. “조작 영역으로 돌아가기”도 제공한다면 목적지를 미리 정해야 하며, 막연히 페이지 맨 위로 돌려보내서는 안 됩니다. 전체 점검은 제출, 대기, 알림 수신, 결과 진입, 다음 행동 선택까지 다뤄야 합니다. “완료되었습니다”가 들렸는지만 확인해서는 부족합니다.

“현재 위치를 유지하고 진입점을 제공하기”는 결과를 덧붙인 뒤에도 사용자가 이전 이야기를 계속 살펴볼 수 있는 상황에 적합합니다. 하지만 모든 페이지에서 유일한 방식일 필요는 없습니다. 조작 이름 자체가 “다음 장 열기”라면 사용자는 이미 새 장으로 들어갈 의사를 표현했습니다. 이때는 장 전환 후의 읽기 시작 위치를 따로 설계할 수 있습니다. 이 규칙을 일반적인 “등대지기에게 묻기”에 그대로 적용해서는 안 됩니다.

사용자가 직접 켜는 “결과가 도착하면 새 내용 읽기” 모드도 설계할 수 있습니다. 이 경우 읽는 범위가 이번 결과에 한정됨을 명확히 하고, 일시 정지와 읽기 위치를 다시 잡는 방법을 제공해야 합니다. 이는 추가적인 읽기 선택지입니다. 상태 알림이 있다는 이유만으로 사용자가 문단 전체의 자동 낭독에 동의했다고 추정해서는 안 됩니다.

“구리 상자를 넣어 두었습니다” 같은 짧은 결과라면 알림에 행동의 결론을 포함할 수 있습니다. 다만 본문이나 다시 확인할 수 있는 기록에도 그 변화를 남겨야 합니다. 새 내용에 궁금증이나 긴장감을 자아내는 대목, 대화, 다음 판단에 필요한 정보가 들어 있다면 알림은 짧게 하고 설명은 본문에 맡기는 편이 좋습니다. 기준은 사용자가 자신의 속도로 읽을 필요가 있는지이며, 글자 수만으로 기계적으로 잘라서는 안 됩니다.

행동이 기존 기록만 바꾸고 이야기를 추가하지 않는다면 “구리 상자 기록이 업데이트되었습니다”라고 알리고 수정된 곳을 가리킵니다. “새 결과”라는 문구를 계속 사용하면 사용자는 존재하지 않는 새 글을 찾게 됩니다.

첫 번째 실패는 페이지 전체의 이야기를 업데이트 알림의 원문으로 사용하는 것입니다. 상자 바닥에 관한 문장 하나가 추가되었을 뿐인데 등대 도입부까지 다시 읽습니다. 점검할 때는 실제로 알린 텍스트의 범위를 기록하고, 이번 조작의 상태만 전달하도록 요구합니다. 이야기 전체는 계속 본문 진입점을 통해 읽게 합니다.

두 번째 실패는 알림은 “완료되었습니다”라고 하지만 본문에는 읽을 결과가 없는 경우입니다. 결과가 준비되고 진입점을 사용할 수 있을 때만 완료를 알려야 합니다. 요청이 실패했다면 이번에는 새 이야기가 추가되지 않았음을 명확히 알리고, 기존 글을 보존하며 재시도 진입점을 제공합니다. 재시도하더라도 같은 결과를 중복해서 덧붙여서는 안 됩니다.

세 번째 실패는 결과가 나타나자마자 초점을 옮기면서 요약까지 읽는 것입니다. 사용자는 원래 위치를 잃고, 비슷한 내용을 연달아 두 번 들을 수도 있습니다. 역할 표에 따라 알림과 이동을 각각 점검합니다. 알림은 상태 변화에 따라 발생하고, 이동은 명시적인 읽기 동작으로 시작되어야 합니다.

네 번째 실패는 연속 행동에서 일어납니다. “업데이트되었습니다”만으로는 어느 조작에 해당하는지 알 수 없습니다. 결과에 알아보기 쉬운 행동 이름을 사용할 수 있습니다. 같은 행동을 여러 번 제출할 수 있다면 각 결과를 구분하고, 아직 읽지 않은 결과도 명확히 표시해야 합니다. 시각적으로 가장 최근 항목이라는 사실만으로 이 관계를 대신해서는 안 됩니다.

마지막으로 실제 대상 기기에서 스크린 리더로 위 상황을 점검합니다. 반복 낭독이 있는지, 위치를 잃는지, 진입점이 새 내용의 시작으로 이동하는지, 알림을 놓친 뒤에도 본문을 다시 찾을 수 있는지 기록합니다. 여기서 제공하는 것은 점검 절차이며, 테스트를 통과했다는 보고서가 아닙니다. 팝업, 페이지 전체 이동, 시간제한이 있는 선택에는 별도의 상호작용 규칙을 작성해야 합니다. 이 결과 추가 점검표로 모든 상황을 포괄할 수는 없습니다.