뉴스

진행 중인 프로젝트

최종 업데이트: 2026년 10월 31일

진행 중

v3: 완전한 QA 도구 모음

2026년 9월 27일

DrupalCon Europe 2026에서 공개

주요 새 기능

• Sa11y와 테스트 코어 통합. 공동 개발한 새 규칙 세트는 핵심 콘텐츠 테스트 규칙 세트에 개발자 테스트, 명도 대비 검사, 가독성 점수 평가를 추가합니다.
• 다국어 지원
• 사용자 정의 검사 빌더
• 대시보드 유지 관리 도구
• 새 결과를 추가하는 사이트 크롤링 도구.
• 특정 역할의 사용자가 일부 테스트(이 PDF는 접근성을 갖추었는가?)의 알림을 사이트 전체에서 닫을 수 있습니다.
• 분리 구성: 개발자 역할과 콘텐츠 역할별로 테스트와 보고서 보기를 나눕니다.

그리고 프로젝트의 미래를 위해 어쩌면 가장 중요한 성과는 다음과 같습니다.

• 보조금을 확보하여 이 후원 조직을 출범시켰습니다. 이 조직은 기존 사용자를 지원하고 향후 프로젝트 아이디어 작업에 자금을 지원합니다.

v2: 알림 닫기 및 보고서

2023년 3월 2일

2년 전 저희는 작성자에게 콘텐츠 개선에 도움이 되는 팁과 함께 즉각적인 피드백을 자동으로 제공하는, 설치 후 바로 쓸 수 있는 Drupal 사이트 플러그인으로 Editoria11y 접근성 검사기를 소개했습니다.

저희는 이 도구가 아직 채워지지 않은 수요를 충족하리라 생각했습니다. 기존 도구는 하나같이 교육과 꾸준한 사용이 뒷받침되어야 쓸모가 있었고, 큰 조직에서 수천 명의 콘텐츠 작성자를 교육하고 관리하는 것이 이 문제를 푸는 효율적인 방법이 아니라는 점은 경험으로 알고 있었습니다. 프로그램이 성공하려면 자동화 수준이 높아야 하며, 흔한 실수가 감지될 때 콘텐츠 작성자에게 정중하게 “필요한 순간의 교육”을 제공해야 한다고 확신했습니다.

효과가 있었습니다.

Princeton에서는 제 커뮤니케이션의 방향이 거의 뒤바뀌었습니다. 이 도구가 설치된 플랫폼에서 저는 대체 텍스트, 링크, 제목을 개선해 달라는 똑같은 이메일을 콘텐츠 작성자에게 보내는 대신, 지적을 덜 받으려면 글을 어떻게 고쳐야 하느냐는 질문을 콘텐츠 작성자에게서 받게 되었습니다.

외부의 반응은 열광이었습니다.

그 자체로 완결된 팁 작성

v1 팁에서는 “요약과 세부 정보” 방식을 택했습니다. 문제를 짧게 설명하고 자세한 내용은 링크로 안내하는 방식입니다.

개발자용으로 작성된 도구에 비하면 나아진 것이었습니다. 팁이 짧고 명확했으니까요. 하지만 어디로 링크할지는 늘 골칫거리였습니다. 일부 정부 및 고등교육 기관 사용자는 Princeton 문서로 연결되는 링크를 없애려고 팁을 수정해야 했고, 그만큼 일이 늘었습니다. 그래서 기본 팁을 인라인 예시가 포함된, 그 자체로 완결된 형태로 다시 작성했습니다.

빨간색 알림(확실한 문제)과 노란색 경고(가능성 있는 문제)의 구분은 혼란스러웠고, 때로는 짜증스럽기까지 했습니다.

그래서 노란색 경고의 의미를 분명히 하기 위해 “수동 검사”로 바꾸고, 작성자가 알림을 닫을 수 있는 버튼을 추가했습니다. “무시한” 알림은 버튼을 클릭한 사람에게만 숨겨지고, “확인 완료로 표시한” 알림은 사이트의 모든 편집자에게 숨겨집니다. 사이트 관리자는 각 작업을 누가 할 수 있는지 정할 수 있습니다.

대시보드 만들기

사이트 소유자들이 흔히 아쉬워한 점은, 도구가 사이트 곳곳의 문제를 잘 찾아내지만 사이트 전체 보고서를 볼 방법이 없다는 것이었습니다.

이번 재작성에서는 검사 결과를 사이트 데이터베이스에 동기화하는 옵션이 추가되었습니다. 이제 사이트 소유자는 페이지별 또는 문제별로 결과를 살펴보고, 어떤 문제가 무시되었거나 확인 완료로 표시되었는지 검토할 수 있으며, 동의하지 않으면 해당 문제를 복원할 수도 있습니다!

개발자를 위한 V2 코드 둘러보기

V2는 거의 전면 재작성이었습니다. 새로운 기능 몇 가지를 소개합니다.

• jQuery 의존성을 없애 더 많은 플랫폼에 설치할 수 있게 되었고, 성능도 2배 향상되었습니다.
• 이제 검사기가 페이지의 독립된 여러 부분(예: 기사 본문과 페이지 바닥글)을 살펴보도록 구성할 수 있습니다.
• 이제 검사기는 여러 웹 컴포넌트와 JavaScript 라이브러리에서 사용하는 섀도 DOM 내부의 요소도 테스트할 수 있습니다.
• 플랫폼 통합을 쉽게 해 주는 새 파라미터가 많이 추가되었습니다. 예를 들어 특정 페이지의 콘텐츠를 책임지지는 않지만 필요할 때 결과를 보고 싶은 사용자에게는 해당 페이지의 모든 문제를 자동으로 무시하도록 설정할 수 있습니다.
• 이제 검사기에 여러 기본 테마와 색상 맞춤 설정 파라미터가 함께 제공됩니다.
• 자동화된 테스트가 코드 회귀를 방지하는 데 도움이 됩니다.

2024 A11yTalks

2024년 6월 11일

Drupal GovCon 2023

2023년 10월 27일

DrupalCamp NJ 2023

2023년 3월 28일

v1: 인라인 도움말

2021년 3월 11일

접근성이 뛰어난 웹 콘텐츠를 만드는 일은 복잡하며, 대개 많은 교육에서 시작합니다.

익숙한 관행은 버리도록 유도해야 합니다.

• 가짜 열을 만들기 위해 표를 사용해서는 안 됩니다
• 본문 텍스트를 가운데 정렬하거나 양쪽 정렬해서는 안 됩니다
• 글꼴 굵기나 크기 같은 시각적 서식만으로 의미를 전달해서는 안 됩니다. 사용자는 콘텐츠를 음성으로 듣거나 “읽기 모드”로 보고 있을 수 있습니다

새로운 관행은 장려해야 합니다.

• 이미지에는 맥락에 맞는 의미 있는 대체 텍스트가 필요합니다
• 페이지에는 실제 구조가 필요합니다
• 링크에는 의미 있는 텍스트가 있어야 합니다

물론 새로운 개념을 가르쳐야 해서 시작한 교육도 있습니다. 하지만 어느 시점에는 이렇게 물어야 합니다. 새로운 기술이 필요한 이유 중 얼마만큼이 개념이 새롭기 때문이고, 얼마만큼이 도구는 그대로 둔 채 새로운 기대만 내놓았기 때문일까요? 무언가가 새롭다고 해서 직관적일 수 없는 것은 아닙니다.

맞춤법의 역사에서 얻는 교훈

1단계: 작성자 탓하기

기록된 역사의 시작부터 1980년대 초까지, 우리는 단어의 철자가 틀리면 작성자를 탓했습니다. 맞춤법을 익힐 책임은 작성자에게 있었습니다.

맞춤법 실력은 어떻게 키웠을까요? 어딘가 익숙하게 들릴 겁니다.

1. 개인 교사에게 배우거나 교실에서 교육을 받았습니다
2. 고대에 점토에 새긴 설형 문자 어휘집까지 거슬러 올라가는 단어 목록, 지침, 사전을 받아 공부했습니다.

2단계: 사전 탓하기

그런데 1980년대에 변화가 일어났습니다. “맞춤법 2단계”라고 부르겠습니다. 가장 널리 쓰이던 워드 프로세서에 맞춤법 검사 기능이 들어간 것입니다.

그렇다면 책임 떠넘기기는 어떻게 되었을까요? 거의 하룻밤 사이에 화살이 도구로 향했습니다.

• 단어의 철자를 모르겠다고요? 대충 입력하고 맞는 단어가 나오길 바랍니다. 안 나오면 사전을 탓합니다.
• 사전이 몰라서 밑줄을 그은 실제 단어를 썼다고요? 투덜거리며 밑줄을 무시할지, 마우스 오른쪽 버튼을 눌러 사전에 추가할지 정합니다.

맞춤법 검사가 우리의 맞춤법 문제를 모두 해결했을까요? 물론 아닙니다. 하지만 도움이 되었습니다. 그리고 부담과 책임의 상당 부분을 작성자에게서 기계로 옮겨 놓았습니다.

하지만 이것이 끝은 아니었습니다…

3단계: 작성 도구 탓하기

최근 몇 년 사이 또 한 걸음 나아갔습니다. 컴퓨터가 우리를 대신해 철자를 쓰기 시작한 것입니다.

• 예측 알고리즘은 다음 단어나 다음 구절, 어쩌면 문자 메시지 답장 전체까지 추측하려 합니다.
• 자동 서식 도구는 별표, 숫자, 문자를 목록으로 바꾸고, 단축 코드를 특수 문자와 이모지로 바꾸려 합니다.
• 받아쓰기 도구는 동음이의어 중 하나를 고르기 위해 개념을 파악하려 합니다.

그럼 이게 엉망이 되면 누가 욕을 먹을까요? 도구입니다!

소셜 미디어 모음 계정들은 민망한 “그런 뜻이 아니었어요!” 스크린샷을 아주 좋아합니다.

Editoria11y는 2단계로 나아가는 한 걸음입니다

저희는 교육에서 테스트를 많이 다루고, 꽤 훌륭한 테스트 도구도 여러 가지 소개합니다. 하지만 어느 도구도 모든 것을 잡아내지는 못합니다. “색상이나 공간적 표현으로 개념을 설명하지 않기” 같은 사항은 사람이 확인해야 하며, 도구는 보통 사이트에 실제로 있는 문제의 절반이 조금 안 되는 정도만 찾아냅니다. 그래도 편집 콘텐츠에서 흔히 저지르는 실수는 아주 잘 찾아냅니다.

다만 세 가지 문제가 있습니다.

1. 대부분 수동 도구입니다. 콘텐츠 작성자는 사용법을 배워야 하고, 글을 쓸 때 도구가 있다는 사실을 기억해야 하며, 다 쓴 뒤 실행하는 것도 잊지 말아야 합니다. 이 세 가지 실패 지점이 맞물려 콘텐츠의 상당수(대부분?)가 검사되지 않은 채 남습니다.
2. 지나치게 많이 표시합니다. 작성자가 방금 저지른 실수만이 아니라 디자이너가 만든 색상 문제, 개발자가 만든 기술적 문제, 정보 제공 목적의 구조 요소 등도 표시합니다. 그만큼 교육의 문턱도 높아집니다. 작성자는 도구를 이해하는 것은 물론, 오탐 목록이나 실제 문제이긴 해도 오늘 이 글을 쓰는 자신이 고칠 일은 아닌 항목을 무시하는 법까지 배워야 합니다.
3. 자동화 도구는 대체로 사이트를 크롤링한 뒤 대시보드를 방문하는 방식을 따릅니다. 이 역시 작성자가 대시보드 방문법을 교육받았고, 잊지 않고 찾아갈 것이라고 가정합니다.

그래서 Princeton은 새로운 것을 만들기로 했습니다. 웹사이트에 통합되어 자동으로 실행되며, 흔한 편집 실수만 살펴보는 검사기입니다.

자동화는…어렵습니다.

1. 자동 검사기는 절제되어야 합니다. 너무 적극적이면 작성자의 작업을 방해하고 짜증 나게 합니다. 너무 점잖으면 쉽게 무시되는 배경 소음이 됩니다.
2. 자동 검사기는 성능이 매우 뛰어나야 합니다. 실행 중에 페이지가 떨리거나 멈칫거리면 작성자는 검사기를 못마땅해하며 꺼 버립니다.
3. 자동 검사기에는 초보자도 이해하기 쉬운 팁이 필요합니다. 많은 작성자에게는 콘텐츠의 접근성을 높여 주는 태그, 구조, 언어에 대해 처음 듣는 자리가 될 것입니다. 알림은 콘텐츠 개선에 실제로 도움이 되는 조언과 함께, 비기술적인 쉬운 언어로 작성되어야 합니다.

그래서 이 목표에 가장 가까운 도구인 Toronto Metropolitan University의 Sa11y에서 출발했습니다. 테스트 아키텍처와 사용자 친화적인 정보 패널 및 툴팁 방식을 가져온 뒤, 반년에 걸쳐 도구를 손질했습니다. 테스트가 항상 자동으로 실행되도록 하고, 성능을 최적화하고, 툴팁을 다듬고, 개발자가 어떤 플랫폼에도 빠르게 적용할 수 있도록 구성 옵션을 잔뜩 만들었습니다.

현재 모습은 다음과 같습니다.

작성자가 사이트에 로그인하면 Editoria11y 토글이 각 페이지의 문제 수와 유형(통과, 수동 검사 필요, 문제 가능성 발견)을 표시합니다. 클릭하면 인라인 강조 표시와 팁을 볼 수 있습니다. 방금 편집한 페이지를 보고 있어서 오류가 새로운 것이라면 패널이 자동으로 열립니다.

2021년 3월 현재, 400개가 넘는 Princeton 웹사이트에서 다음 항목을 자동으로 검사합니다.

• 좋은 문서 개요
  • 건너뛴 제목 레벨
  • 빈 제목
  • 너무 긴 제목
  • 실제로는 제목일 수 있는, 의심스러울 만큼 짧은 인용구
• 대체 텍스트
  • 대체 텍스트가 없는 이미지
  • 파일 이름이 대체 텍스트로 쓰인 이미지
  • 대체 텍스트가 너무 긴 이미지
  • “~ 이미지”나 “~ 사진”처럼 불필요한 표현이 포함된 대체 텍스트
  • 링크 안의 이미지 중 대체 텍스트가 링크 대상이 아니라 이미지를 설명하는 것으로 보이는 경우
  • 보통 대체 텍스트가 필요한 임베드 시각화 자료
• 의미 있는 링크
  • 텍스트가 없는 링크
  • 파일 이름을 링크 텍스트로 쓴 링크
  • “여기를 클릭”, “자세히 알아보기”, “다운로드” 같은 일반적인 텍스트만 쓴 링크
  • 외부 링크 아이콘 없이 새 창에서 열리는 링크
• 일반 품질 보증
  • 별표, 숫자, 문자 대신 목록 서식을 사용하는지 확인
  • CAPS LOCK으로 입력한 대량의 텍스트
  • 헤더이 없는 표, 그리고 표 헤더(<th>) 대신 문서 제목(“제목 3”)을 사용한 표
  • PDF 및 기타 문서로 연결되는 링크(다운로드 파일의 접근성을 테스트하거나 접근 가능한 대체 형식을 제공하도록 사용자에게 안내)
  • 임베드된 동영상(폐쇄 자막을 추가하도록 사용자에게 안내)
  • 임베드된 오디오(대본을 제공하도록 사용자에게 안내)
  • 임베드된 소셜 미디어(alt 요소를 제공하도록 사용자에게 안내)

저희는 JavaScript 라이브러리를 커뮤니티에 공개하고, 설치 후 바로 쓸 수 있는 Drupal 통합을 만들었으며, 같은 방식의 WordPress 통합 작업도 시작했습니다.

3단계를 향하여: 기본적으로 접근 가능하게

여러 면에서 Editoria11y는 임시방편입니다. 이 도구가 잡아내는 실수 대부분은 콘텐츠 작성자에게 새로운 기대(“콘텐츠에 좋은 구조를 태그하세요”)를 걸면서 정작 그 반대를 부추기는 도구를 건네주었기 때문에 생긴 것입니다.

앞으로 나아갈 길은 접근성 높은 콘텐츠를 더 쉽게, 그리고 최대한 자동으로 만들 수 있게 하는 것입니다. 구체적인 모습은 아직 분명하지 않지만 아마 다음과 같은 것들이 포함될 것입니다.

• 어떤 옵션을 제공할지 다시 생각하기. 예를 들어 웹에서 텍스트를 양쪽 정렬하지 말라고 계속 말하고 있다면, 이제 “양쪽 정렬” 버튼을 없앨 때가 되지 않았을까요?
• 기본 옵션을 다시 생각하기. 예를 들어 대부분의 콘텐츠 관리 시스템에서 기본 표에는 헤더이 없습니다. “속성”을 클릭해 접근성 기능을 추가해야 한다는 것을 아는 일은 사용자의 몫입니다. 이제 이를 뒤집을 때가 아닐까요?
• 예측 서식과 “작업 중 힌트”를 고민하기. 사용자가 한 줄 전체를 굵게 만들면 제목으로 바꾸도록 제안할 수 있을까요? 사용자가 제목을 선택하려 할 때 여섯 가지 옵션을 모두 보여 주는 대신 원하는 제목 레벨을 짐작할 수 있을까요? 어려운 개념에 대해 필요한 순간에 바로 교육을 제공할 수 있을까요?