사려 깊은 파일 변환을 통한 문서 접근성 확보

접근성은 단순한 체크리스트가 아니라, 장애 여부와 관계없이 모든 사람이 디지털 콘텐츠를 쉽게 이용할 수 있도록 보장하는 디자인 철학입니다. 문서가 한 형식에서 다른 형식으로 이동할 때, 화면 읽기 프로그램과 보조 기술이 활용하는 구조, 태그, 설명이 손실되거나 손상될 수 있습니다. 의미론을 고려하지 않고 시각적 모습만을 재현하는 변환은 화면에서는 괜찮아 보이지만 키보드 탐색, 음성 비서, 점자 디스플레이 등에 의존하는 사용자에게는 큰 장애물이 됩니다. 이 글에서는 파일 변환 과정에서 접근성을 유지하고 심지어 향상시키기 위한 실용적인 단계들을 살펴보고, 가장 흔히 사용되는 원본·대상 형식, 의미론적 마크업의 기술적 세부 사항, 그리고 준수 여부를 검증하는 도구들을 소개합니다.

접근성 요구사항 이해하기

접근 가능한 문서 디자인의 핵심은 인식가능성, 조작가능성, 이해가능성이라는 세 가지 기둥입니다.

  • 인식가능성은 모든 정보를 사용자가 시각·청각·촉각 등으로 감지할 수 있는 형태로 제공해야 함을 의미합니다.
  • 조작가능성은 키보드나 다른 대체 입력 방법으로도 탐색과 상호 작용이 가능해야 함을 요구합니다.
  • 이해가능성은 명확하고 논리적인 구조와 예측 가능한 동작을 요구합니다.

파일을 변환할 때, 각 기둥은 구체적인 기술적 기대치로 바뀝니다.

  • PDF의 경우, PDF/UA(Universal Accessibility) 표준은 태그가 지정된 콘텐츠, 정확한 읽기 순서, 비텍스트 요소에 대한 대체 텍스트를 요구합니다.
  • EPUB에서는 EPUB Accessibility 1.0 사양이 의미론적 HTML, 필요한 경우 ARIA 역할, 올바른 내비게이션 랜드마크를 요구합니다.
  • Word 문서는 제목 스타일, 목록 구조, 대체 텍스트를 유지해야 합니다. 변환 과정에서 이러한 속성 중 하나라도 누락하면 보조 소프트웨어가 문서를 오해하여 혼란이나 정보 누락을 초래할 수 있습니다.

올바른 대상 형식 선택하기

모든 형식이 접근성을 똑같이 지원하는 것은 아닙니다. 선택은 대상 독자의 필요, 배포 채널, 선택한 형식의 기술적 한계를 균형 있게 고려해야 합니다.

  • PDF/UA – 레이아웃 정확성을 유지해야 하는 정적·인쇄용 문서에 가장 적합합니다. 법률 계약서, 학술 논문, 정부 양식 등에 활용됩니다.
  • EPUB(접근성 확장 포함) – 소설, 매뉴얼, 교육 가이드처럼 텍스트가 재흐름할 필요가 있는 경우에 이상적이며, 독자가 글자 크기를 조정하거나 다크 모드로 전환할 수 있습니다.
  • HTML – 문서를 온라인에서 제공할 경우, 구조가 잘 잡힌 HTML 페이지가 가장 풍부한 접근성 기능을 제공합니다.
  • DOCX – 후속 편집이 필요할 때 유용하지만, 편집 환경(예: Microsoft Word)이 접근성 메타데이터를 제대로 보존할 경우에만 사용합니다.

이러한 트레이드오프를 이해하면 편리함을 위해 접근성을 희생하지 않는 변환 경로를 선택할 수 있습니다.

의미론적 구조 보존하기

접근성 실패의 가장 흔한 원인은 의미론 정보—제목, 목록, 표, 읽기 순서—가 손실되는 것입니다. 변환 엔진은 모든 내용을 평문이나 래스터 이미지로 평탄화하지 않고, 원본 마크업을 대상 형식의 동등한 태그에 매핑해야 합니다.

Word → PDF/UA

Microsoft Word는 구조 정보를 스타일 정의(예: Heading 1, Heading 2, List Paragraph)에 저장합니다. PDF로 내보낼 때 “Create tagged PDF” 옵션을 활성화하세요. 그러면 Word가 스타일 계층을 PDF 태그로 삽입하고, 화면 읽기 프로그램이 이를 논리적 개요로 해석합니다. 서드‑파티 변환기를 사용할 경우, “Heading”·“Structure” 태그를 유지하는지 확인하고, 그렇지 않다면 Adobe Acrobat Pro와 같은 도구로 누락된 태그를 수동으로 추가해야 합니다.

PDF → EPUB

정적 PDF를 재흐름 EPUB으로 변환하는 일은 PDF에 논리 순서가 부족한 경우가 많아 어려움이 큽니다. 강력한 변환 워크플로는 PDF 내부 텍스트 객체를 추출하고, 공백을 분석해 단락을 추정한 뒤, 의미론적 HTML 트리를 재구성합니다. OCR과 레이아웃 분석을 결합한 pdf2epub(머신러닝 백엔드)와 같은 도구가 단순 비트맵‑투‑텍스트 변환기보다 우수한데, 이는 제목·목록을 보존하면서 모든 내용을 하나의 연속 블록으로 전환하지 않기 때문입니다.

이미지 → 접근 가능한 형식

문서에 텍스트가 스캔된 이미지가 포함돼 있다면, 변환 전에 OCR(광학 문자 인식)을 실행해야 합니다. OCR은 텍스트를 추출할 뿐 아니라, 제목·표·그림 캡션에 적절한 태그를 지정할 수 있게 합니다. ABBYY FineReader와 같은 OCR 엔진은 인식된 텍스트를 바로 PDF/UA에 삽입해 검색 가능 레이어와 선택 가능한 제목을 포함시킵니다.

이미지와 대체 텍스트 다루기

이미지는 차트, 다이어그램, 장식 아이콘, 사진 등 다양한 의미를 전달합니다. 화면 읽기 사용자에게는 **대체 텍스트(alt text)**가 유일한 전달 수단입니다. 변환 시 다음 절차를 따르세요.

  1. 이미지 요소 감지 – HTML에서는 <img> 태그, PDF에서는 이미지 객체를 찾습니다.
  2. 기존 alt 속성 추출 – 최신 저작 도구는 이미 alt 텍스트를 저장하고 있으니 그대로 유지합니다.
  3. 누락된 alt 텍스트 생성 – 소스에 설명이 없을 경우, Microsoft Azure Computer Vision 등 AI 기반 캡션 서비스를 활용해 간결한 설명을 자동 생성합니다. 자동 캡션은 뉘앙스를 놓칠 수 있으니 반드시 수동 검토합니다.
  4. alt 텍스트 삽입 – PDF에서는 /ActualText 엔트리로, EPUB/HTML에서는 alt 속성으로 저장합니다.

장식용 이미지에 설명을 전혀 달지 않는 유혹을 피하세요. HTML에서는 role="presentation"이나 빈 alt=""를 사용해 순수 장식임을 알릴 수 있습니다. PDF/UA에서는 /Artifact 플래그를 설정해 보조 기술이 이미지를 건너뛰도록 합니다.

표와 복합 레이아웃 관리하기

표는 데이터와 시각적 서식을 동시에 담고 있기 때문에 접근성 오류가 자주 발생합니다. 표를 이미지로 변환하면 셀 간 관계가 사라져 보조 소프트웨어가 정보를 전달할 수 없습니다.

  • 표 의미 보존 – 대상 형식에 <table>, <thead>, <tbody>, <th> 태그(또는 PDF 표 태그)를 정확히 포함시킵니다. Word에서 변환할 경우, HTML 표로 매핑한 뒤 PDF를 만들도록 “Table conversion” 옵션을 활성화합니다.
  • 요약 및 캡션 제공 – HTML·PDF/UA 모두 간단한 요약을 지원합니다. HTML에서는 <caption> 요소, PDF에서는 Table Caption 태그에 넣어 표의 목적을 설명합니다.
  • 중첩 표 피하기 – 중첩 구조는 읽기 순서를 깨뜨리기 쉽습니다. 레이아웃용으로 중첩 표를 사용한 경우, 단일 표로 재구성하거나 CSS를 이용해 시각적 정렬을 구현하는 것이 좋습니다.

다중 컬럼 레이아웃을 갖는 재무 보고서와 같은 복잡한 보고서는 먼저 논리적 섹션으로 나눈 뒤, 각 섹션을 개별적으로 변환해 깔끔한 마크업 계층을 유지하세요.

접근 가능한 PDF 만들기 (PDF/UA)

PDF/UA 준수는 까다롭지만 달성 가능한 목표입니다. 변환 과정은 크게 세 단계로 나눌 수 있습니다.

  1. 소스 준비 – 저작 도구에서 제목·목록 스타일과 alt 텍스트를 적용합니다. Word의 접근성 검사기, Adobe InDesign의 접근성 패널 등 내장 검사기로 사전 문제를 해결합니다.
  2. 태그가 포함된 내보내기 – 문서를 태그가 포함된 PDF로 내보냅니다. Word에서는 File → Save As → PDF 선택 후 “Best for electronic distribution and accessibility” 옵션을 체크합니다. InDesign에서는 “Create Tagged PDF”와 “Include Structure Tags for Accessibility”를 활성화합니다.
  3. 내보낸 뒤 검증PAC 3(PDF Accessibility Checker) 또는 무료 pdfaPilot 같은 검증 도구를 실행해 누락된 태그, 태그가 없는 이미지, 읽기 순서 문제 등을 스캔합니다. 발견된 문제는 Acrobat Pro에서 수동으로 수정하거나 원본 파일을 다시 편집합니다.

대량의 PDF를 변환해야 한다면 Ghostscriptpdf2pdf 스크립트를 활용한 자동 파이프라인을 구축해 태그를 보존할 수 있지만, 메타데이터가 제거되지 않았는지 샘플을 반드시 확인해야 합니다.

전자책(EPUB)에서의 접근성

전자책은 재흐름 가능성이 기본이기 때문에 또 다른 도전 과제가 존재합니다. EPUB은 HTML·CSS·이미지 파일을 압축한 형태이며, 접근성을 확보하려면 다음을 지켜야 합니다.

  • 올바른 제목 계층 사용<h1>~`
    ` 태그가 장과 절의 논리적 개요를 정확히 반영하도록 합니다.
  • 내비게이션 문서 제공nav.xhtml 파일은 화면 읽기 프로그램용 목차 역할을 합니다. 각 항목이 올바른 랜드마크를 가리키는지 확인합니다.
  • ARIA 랜드마크 추가 – 복잡한 페이지에서는 role="navigation", role="main", role="complementary" 등을 넣어 사용자가 주요 섹션으로 빠르게 이동할 수 있게 합니다.
  • 이미지 설명 포함 – PDF와 마찬가지로 모든 이미지에 alt 속성을 삽입합니다.
  • EPUBCheck로 검증 – W3C의 EPUBCheck 도구가 누락된 랜드마크, 참조되지 않은 파일, 기타 접근성 결함을 표시합니다.

DOCX → 접근 가능한 EPUB 변환은 LibreOffice의 Export as EPUB 기능으로 할 수 있지만, “Export headings as structure” 옵션을 켜고 결과 HTML에 누락된 alt 텍스트를 수동으로 추가해야 합니다. 보다 안정적인 결과를 원한다면 EPUB Accessibility 사양을 준수하는 전용 변환 서비스를 고려하세요.

테스트 및 검증 도구

변환 워크플로는 체계적인 테스트 없이는 완성될 수 없습니다. 형식별로 가장 신뢰할 수 있는 도구를 정리하면 다음과 같습니다.

  • PDF/UAPAC 3, Adobe Acrobat Pro의 접근성 검사기, NVDA(무료 화면 읽기 프로그램)로 수동 탐색 확인.
  • EPUBEPUBCheck, Ace by DAISY, macOS의 VoiceOver로 읽기 순서 검증.
  • HTMLWAVE Web Accessibility Evaluation Tool, axe DevTools, 그리고 화면 읽기 프로그램을 이용한 수동 검사.
  • DOCX – Microsoft Word 내장 Accessibility Checker, 이후 NVDA로 제목·목록 구조를 확인.

각 변환 후 이러한 도구를 실행하면 회귀 문제를 초기에 포착할 수 있습니다. 대규모 자동 변환을 수행한다면 CI 파이프라인에 통합하는 것이 좋습니다.

일관된 결과를 위한 워크플로 팁

  1. 소스 스타일 표준화 – 변환 전 모든 문서에 스타일 가이드를 적용합니다. 일관된 제목 수준, 목록 형식, 이미지 라벨링은 자동 매핑을 예측 가능하게 합니다.
  2. 변환 체크리스트 작성 – 필요한 접근성 속성(태그, alt 텍스트, 캡션 등)을 목록화하고, 변환 후 각각을 확인합니다.
  3. 가능하면 단일 변환 엔진 사용 – 여러 도구를 오가면 변형이 발생합니다. convertise.app과 같이 태그를 보존하고 배치를 스크립트화할 수 있는 클라우드 기반 서비스가 배치 처리에 유리합니다.
  4. 예외 상황 문서화 – 변환기가 복잡한 표 등을 제대로 처리하지 못하는 경우, 해당 파일을 기록하고 수동 보정 작업을 계획합니다.
  5. 버전 관리 – 소스와 변환 파일을 Git과 같은 저장소에 보관해 접근성 결함을 일으킨 변경 이력을 추적합니다.

이러한 습관을 일상에 녹이면 팀이 접근성 없는 문서를 출시할 위험을 크게 줄일 수 있습니다.

흔히 저지르는 실수와 회피 방법

  • PDF 평탄화 – PDF를 이미지 전용 버전으로 변환하면 검색 가능성·태그가 모두 사라집니다. 원본 PDF를 그대로 보관하고, 반드시 편집이 필요할 때만 이미지를 래스터화하세요.
  • 시각적 레이아웃에만 의존 – 보기 좋은 페이지라도 읽기 순서가 뒤섞일 수 있습니다. Acrobat의 “Reading Order” 패널이나 브라우저의 DOM 검사기로 논리 흐름을 확인합니다.
  • 언어 속성 누락 – 다국어 문서의 경우 HTML/EPUB는 루트 요소에 lang="en"·lang="fr" 등을, PDF는 Language 태그를 명시해야 화면 읽기 프로그램이 올바른 발음 규칙을 적용합니다.
  • 기본 alt 텍스트에 의존 – “image1”과 같은 일반적인 설명은 전혀 도움이 되지 않습니다. 이미지가 전달하려는 목적을 반영한 구체적인 설명으로 교체하세요.
  • 검증 단계 생략 – 태그 하나가 빠져도 화면 읽기 프로그램의 탐색이 중단될 수 있습니다. 검증은 선택 사항이 아니라 필수 단계로 간주합니다.

결론

접근성은 사후 작업이 아니라 변환 프로세스의 필수 요소입니다. 의미론적 구조, 대체 텍스트, 표 마크업, 언어 속성을 일등 시민처럼 다루면 일반 파일을 모든 사용자가 활용할 수 있는 보편적 자원으로 탈바꿈시킬 수 있습니다. 이 여정은 일관된 제목 사용·적절한 alt 텍스트·명료한 표 작성이라는 disciplined authoring에서 시작해, 목표 형식 선택과 정확한 변환을 거쳐, 특화된 도구를 활용한 철저한 검증으로 마무리됩니다. 이러한 단계가 반복 가능한 워크플로에 녹아들면 조직은 법적·윤리적 요구를 충족할 뿐 아니라, 디지털 커뮤니케이션 전체의 품질과 전문성을 한층 높일 수 있습니다.