Windows 앱 접근성 입문 ── UI Automation과 합리적 배려 의무화에 대비하기

「중도 채용한 시각장애 직원이 핵심 수주 입력 앱을 스크린 리더로 쓸 수 없습니다. 웹 브라우저와 메일은 문제없이 다루는데, 우리 업무 앱만 읽기가 제대로 되지 않습니다. 어떻게 안 될까요」── 고객 정보시스템 부서에서 이런 상담을 받는 일이 늘었습니다.

배경 하나는 법제도입니다. 2021년에 개정된 장애인차별해소법이 2024년 4월 1일 시행되어, 사업자에게도 장애인에 대한 「합리적 배려의 제공」이 의무화되었습니다.¹ 덧붙이면, 서두와 같은 직원과 회사의 관계(고용 분야)는 장애인고용촉진법의 영역이고, 이쪽은 2016년 4월부터 사업주에게 합리적 배려 제공이 의무입니다.² 「접근성은 웹사이트 이야기이고, 사내 Windows 앱과는 무관하다」는 인식은 법제도 면에서도 실무 면에서도 더 이상 성립하지 않습니다.

한편 개발 현장에서 보면 「무엇을 하면 되는지 모르겠다」가 솔직한 심정일 것입니다. Windows 데스크톱 앱의 접근성은 웹만큼 정보가 없고, 나중에 얹는 마법 같은 해결책도 없습니다. 그렇다고 비관할 필요도 없습니다. 스크린 리더가 앱을 읽는 기반(UI Automation)을 이해하고, 이름·키보드·색이라는 기본을 잡으면 업무 앱의 사용성은 크게 좋아집니다. 게다가 그 상당수는 장애 유무와 관계없이 모든 사용자의 생산성을 올리는 개선입니다.

이 글에서는 일본의 업무 앱 개발자와 정보시스템 담당자를 대상으로, 법제도와 규격의 최소 정리부터 UI Automation의 구조, WinForms/WPF 구현, 키보드 조작, 색과 대비, 검증 도구, 현실적인 우선순위 정하기까지를 한 흐름으로 잇습니다.

flowchart TB
    accTitle: 이 글의 흐름
    accDescr: 법제도와 규격 정리부터 UI Automation의 구조, WinForms와 WPF 구현, 키보드 조작, 색과 대비, 검증 도구, 우선순위 정하기까지를 차례로 잇는 이 글의 구성
    law["법제도와 규격 정리"] --> uia["UI Automation의 구조"]
    uia --> impl["WinForms/WPF 구현"]
    impl --> kb["키보드 조작"]
    kb --> color["색과 대비"]
    color --> verify["검증 도구"]
    verify --> prio["우선순위 정하기"]

그림 1: 이 글은 법제도에서 구조·구현·검증·우선순위까지를 하나의 흐름으로 잇습니다.

1. 먼저 결론

• 합리적 배려의 제공은 2024년 4월 1일부터 사업자에게도 의무입니다. 장애인이 장벽을 없애 달라는 의사를 나타냈을 때, 부담이 지나치지 않은 범위에서 대응하는 것이 요구됩니다. 고용 분야는 장애인고용촉진법의 대상이며, 이쪽은 2016년 4월부터 사업주의 의무입니다.¹²
• 합리적 배려는 「개별 신청에 건설적 대화로 응하는」 과정이고, 앱의 사전 수정은 「환경 정비」(노력 의무)에 해당합니다. 완벽한 사전 대응이 의무가 아니라, 대화를 일방적으로 거부하지 않는 것이 중요합니다.¹
• 접근성의 기술 기준은 WCAG(JIS X 8341-3:2016)에 모입니다. JIS X 8341-3:2016은 WCAG 2.0과 같은 내용의 일치 규격이고, W3C의 WCAG2ICT가 비웹 소프트웨어에 적용하는 안내를 제시합니다. 데스크톱 앱도 같은 생각으로 점검할 수 있습니다.³⁴
• 스크린 리더는 UI Automation(UIA)을 통해 앱을 읽습니다. UIA 트리의 각 요소가 가진 Name·ControlType 같은 속성과 Invoke·Value·SelectionItem 같은 컨트롤 패턴이 읽기와 조작의 재료입니다.⁵
• Name이 비어 있는 버튼은 「버튼」이라고만 읽힙니다. 최우선 수정은 이름 지정입니다. WinForms는 AccessibleName과 Label·탭 순서 연결, WPF는 AutomationProperties.Name/LabeledBy로 대응합니다.⁶⁷
• 모든 기능에 키보드만으로 도달할 수 있는 것은 WCAG 성공 기준(2.1.1)인 동시에, 숙련 오퍼레이터의 입력 속도 그 자체입니다. 탭 순서·액세스 키·포커스 표시를 갖추는 일은 모든 사용자의 효율로 직결됩니다.⁸
• 텍스트 대비비는 4.5:1 이상을 가이드로 삼고, 색만으로 정보를 전하지 마십시오. 대비 테마(고대비)에서는 하드코딩한 색이 아니라 시스템 색을 존중합니다.⁸⁹
• 검증은 Accessibility Insights for Windows의 FastPass와 스크린 리더 현장 확인을 조합합니다. 같은 UIA 기반 위에 있으므로, 이 정비는 FlaUI 등의 UI 자동 테스트 자산과도 서로 맞물립니다.¹⁰
• 전 화면을 한 번에 고칠 필요는 없습니다. ①그 이용자가 쓰는 화면부터, ②신규 개발분은 표준으로 대응, ③공통 컨트롤 수정으로 다른 화면에 파급, 이라는 순서가 현실적인 해법입니다.

한 문장으로 정리하면, 접근성 대응이란 「UIA 트리에 올바른 이름과 조작을 공개하고, 키보드와 색의 기본을 지키는 것」입니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 16건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 법제도와 규격 정리 ── 「의무화」로 무엇이 바뀌었는가

2.1. 장애인차별해소법 ── 2024년 4월부터 사업자에게도 「합리적 배려의 제공」이 의무

장애인차별해소법은 행정기관 등과 사업자에 대해, 장애인에 대한 「부당한 차별적 취급」을 금지하고 「합리적 배려의 제공」을 요구하는 법률입니다. 2021년(레이와 3년) 개정으로, 그때까지 노력 의무였던 사업자에 의한 합리적 배려 제공이 의무로 바뀌었고, 개정법은 2024년(레이와 6년) 4월 1일에 시행되었습니다.¹

내각부 리플릿에 따르면, 합리적 배려의 제공이란 장애인이 사회 안의 장벽을 없애기 위해 어떤 대응이 필요하다고 의사를 나타냈을 때, 부담이 지나치지 않은 범위에서 대응하는 것입니다. 그 내용은 장애 특성과 장면·상황에 따라 다르므로, 장애인과 사업자가 대화를 거듭하며 함께 대응안을 검토하는 「건설적 대화」가 중시됩니다. 건설적 대화를 일방적으로 거부하는 일은 합리적 배려 제공 의무 위반이 될 수 있다고 명시되어 있습니다.¹

여기서 실무상 중요한 정리는 두 가지입니다.

1. 「사전에 모두 대응해 두는 것」이 의무화된 것은 아닙니다. 매뉴얼 재검토나 연수 같은 소프트면, 시설 배리어프리 같은 하드면처럼, 불특정 다수의 장애인을 대상으로 하는 사전 개선 조치는 「환경 정비」라 불리며, 이쪽은 노력 의무입니다.¹ 업무 앱을 미리 스크린 리더로 쓸 수 있는 상태로 갖추어 두는 일은 이 환경 정비 쪽 대응으로 볼 수 있습니다. 환경 정비가 진행될수록 개별 합리적 배려는 가벼운 부담으로 제공할 수 있습니다.
2. 고용 분야는 장애인차별해소법이 아니라 장애인고용촉진법의 대상입니다. 같은 리플릿에도 고용·취업은 장애인고용촉진법 규정에 따른다고 적혀 있습니다.¹ 그리고 장애인고용촉진법에서는 2016년(헤이세이 28년) 4월 시행 개정으로, 고용 분야의 장애인 차별 금지와, 과중한 부담이 되지 않는 범위의 합리적 배려 제공이 사업주에게 의무입니다.² 서두의 「직원이 업무 앱을 쓸 수 없다」는 상담은, 실은 2024년보다 훨씬 전부터 의무 영역이었습니다.

flowchart TB
    accTitle: 합리적 배려와 환경 정비의 위치
    accDescr: 일반 사업자와 장애인의 관계는 장애인차별해소법의 대상이며 개별 신청에 건설적 대화로 응하는 합리적 배려의 제공이 2024년 4월부터 의무, 고용 분야는 장애인고용촉진법에 따라 2016년 4월부터 사업주 의무, 앱의 사전 수정은 노력 의무인 환경 정비에 해당한다
    scene{"어느 장면인가?"} -->|사업자와 장애인| kaisho["장애인차별해소법"]
    scene -->|고용·취업 장면| koyou["장애인고용촉진법"]
    kaisho --> moushide["개별 신청에 건설적 대화로 대응"]
    moushide --> hairyo["합리적 배려의 제공（2024년 4월부터 의무）"]
    koyou --> koyougimu["합리적 배려의 제공（2016년 4월부터 의무）"]
    kaisho -.-> kankyo["사전 앱 수정=환경 정비（노력 의무）"]
    kankyo -.-> moushide

그림 2: 장면에 따라 근거법이 나뉘고, 합리적 배려는 의무, 사전 수정은 환경 정비로서 노력 의무에 해당합니다.

다만 개별 사례가 법률상 어떻게 다뤄지는지는 상황에 따라 다릅니다. 이 글은 법해석에 들어가지 않고, 대응을 요청받았을 때 기술자로서 무엇을 할 수 있는가라는 관점으로 진행합니다. 1차 정보로는 내각부·후생노동성 자료를 참조하십시오.¹²

2.2. JIS X 8341-3과 WCAG ── 「웹의 기준」은 소프트웨어에도 이어진다

기술 기준 쪽은 JIS X 8341-3:2016에 모입니다. 이 규격은 ISO/IEC 40500:2012의 일치 규격이고, 규격 본문은 W3C의 WCAG 2.0과 같은 내용입니다.³ 「접근성 대응」의 내용을 구체적으로 알고 싶다면 WCAG 성공 기준(현재는 WCAG 2.1/2.2로 확장)을 읽는 길이 빠르고, WAIC의 일본어 번역도 공개되어 있습니다.⁸

「WCAG는 웹 콘텐츠의 기준 아닌가」라는 의문은 타당하지만, W3C는 WCAG2ICT(Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies)라는 Group Note에서 WCAG 2.0/2.1/2.2 성공 기준을 비웹 문서와 소프트웨어에 적용하는 방법을 정리합니다.⁴ 즉 「텍스트 대체」「대비」「키보드 조작」「색에만 의존하지 않기」 같은 생각은 Windows 데스크톱 앱에도 웹과 같은 틀로 적용할 수 있습니다. 이 글의 3장 이후는 이 생각을 WinForms/WPF의 구체적인 구현으로 내리는 내용입니다.

flowchart TB
    accTitle: JIS X 8341-3과 WCAG의 관계
    accDescr: JIS X 8341-3:2016은 WCAG 2.0과 같은 내용의 일치 규격이며, WCAG2ICT가 WCAG 성공 기준을 비웹 소프트웨어에 적용하는 방법을 보이므로 Windows 데스크톱 앱도 같은 틀로 점검할 수 있다
    wcag["WCAG 2.0（W3C）"] ---|같은 내용의 일치 규격| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["비웹 소프트웨어에 적용"]
    soft --> app["Windows 데스크톱 앱"]

그림 3: JIS X 8341-3:2016은 WCAG 2.0의 일치 규격이고, WCAG2ICT가 같은 기준을 데스크톱 앱으로 이어 줍니다.

3. 보조 기술이 앱을 읽는 구조 ── UI Automation의 3점 세트

3.1. UIA 트리·속성·컨트롤 패턴

Windows에는 UI Automation(UIA)이라는 접근성 기반이 들어 있습니다. UIA는 스크린 리더 같은 보조 기술이 UI 정보를 얻고, 표준 입력 이외의 수단으로 UI를 조작할 수 있게 하는 장치이며, 앱 측(프로바이더)과 보조 기술 측(클라이언트) 사이를 잇습니다.⁵

UIA의 세계는 다음 3점 세트로 이해할 수 있습니다.⁵

스크린 리더가 버튼에 포커스했을 때 읽는 「수주 확정 버튼」은 대체로 Name+컨트롤 종류의 조합입니다. 사용자가 「실행」 조작을 하면 보조 기술은 Invoke 패턴으로 그 버튼을 누릅니다. 즉 Name과 패턴이 올바르게 공개되어 있으면 읽고 조작할 수 있고, 공개되어 있지 않으면 화면에 보여도 없는 것과 같습니다.

flowchart TB
    accTitle: UI Automation의 3점 세트
    accDescr: 앱은 프로바이더로서 UIA 트리에 각 요소의 속성과 컨트롤 패턴을 공개하고, 스크린 리더는 클라이언트로서 Name과 ControlType을 읽으며 Invoke 등의 패턴으로 조작한다
    app["앱（프로바이더）"] --> tree["UIA 트리"]
    tree --> prop["속성（Name·ControlType 등）"]
    tree --> pat["패턴（Invoke·Value 등）"]
    sr["스크린 리더（클라이언트）"] -->|읽기| prop
    sr -->|조작| pat

그림 4: 앱이 UIA 트리에 공개한 속성과 패턴을 스크린 리더가 읽기와 조작에 씁니다.

3.2. 스크린 리더는 UIA의 클라이언트

Windows에서 쓰이는 주요 스크린 리더에는 Windows에 들어 있는 내레이터, 무료·오픈 소스인 NVDA¹¹, 일본 국내에서 널리 쓰이는 상용 PC-Talker 등이 있습니다. 읽는 방식은 저마다 다르지만, 데스크톱 앱 UI를 읽기 위한 주요 경로는 모두 UIA입니다. 그래서 앱 측 대응은 「특정 스크린 리더 대응」이 아니라 UIA에 올바른 정보를 공개하는 것으로 모입니다.

flowchart TB
    accTitle: 주요 스크린 리더의 공통 경로
    accDescr: 앱이 UIA에 올바른 정보를 공개하면 내레이터와 NVDA와 PC-Talker 모두 같은 경로로 UI를 읽을 수 있으므로, 앱 측 대응은 특정 스크린 리더용이 아니라 UIA로의 공개로 모인다
    app["앱"] -->|정보를 공개| uia["UI Automation（UIA）"]
    uia --> nar["내레이터"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["대응은 UIA로의 공개로 모인다"]

그림 5: 주요 스크린 리더는 모두 UIA를 경로로 쓰므로, 앱 대응은 UIA로의 공개로 모입니다.

3.3. 「Name이 비어 있는 버튼」은 무엇으로 읽히는가

구체 예를 하나 듭니다. 도구 모음에 플로피 디스크 아이콘만 표시한 저장 버튼이 있다고 합시다. 눈이 보이는 사용자에게는 아이콘으로 의미가 전달되지만, Name이 비어 있으면 스크린 리더는 이 버튼을 「버튼」이라고만 읽습니다. 옆에 늘어선 「열기」「인쇄」도 같다면 사용자에게는 「버튼, 버튼, 버튼」으로만 들리고, 무엇이 무엇인지 알 수단이 없습니다. Microsoft의 접근성 수정 가이드에서도, Name이 없는 버튼이나 「Image」라고만 읽히는 이미지는 사용자의 작업을 멈추는 대표적인 문제로 꼽힙니다.⁷

다행히 WinForms도 WPF도 표준 컨트롤은 처음부터 UIA 대응을 갖추고, 많은 경우 텍스트나 레이블에서 Name이 자동으로 정해집니다. 깨지는 경우는 대개 ①아이콘만 있어 이름의 재료가 없다, ②레이블과 연결이 없다, ③자체 그리기로 UIA 트리에 정보가 나오지 않는다, 중 하나입니다. 다음 두 장에서 프레임워크별 고치는 법을 봅니다.

flowchart TB
    accTitle: 읽기가 깨지는 세 가지 전형
    accDescr: 아이콘만 있어 이름의 재료가 없는 경우와 레이블 연결이 없는 경우와 자체 그리기로 UIA 트리에 정보가 나오지 않는 경우에 읽기가 깨져 버튼이라고만 읽히는 상태가 된다
    c1["아이콘만 있어 재료 없음"] --> broken["Name이 비게 된다"]
    c2["레이블 연결 없음"] --> broken
    c3["자체 그리기로 정보가 나오지 않음"] --> broken
    broken --> result["버튼이라고만 읽힌다"]

그림 6: 읽기가 깨지는 경우는 대개 이름 재료 부족·연결 부족·자체 그리기 세 패턴으로 귀결됩니다.

4. WinForms 구현 ── AccessibleName과 탭 순서

4.1. Text가 자동으로 Name이 되는 컨트롤과, 되지 않는 컨트롤

WinForms에서는 Button이나 CheckBox처럼 글자를 표시하는 컨트롤은 Text 속성 값이 UIA의 Name으로 쓰입니다. 반면 ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView 등은 Text가 Name이 되지 않습니다. 이들에게는 다른 수단으로 이름을 주어야 합니다.⁶

가장 유지보수하기 쉬운 방법은 설명용 Label을 대상 컨트롤의 직전 탭 순서에 두는 것입니다. Label의 TabIndex 바로 다음에 대상 컨트롤의 TabIndex가 오도록 설정하면, 그 Label의 텍스트가 UIA Name으로 자동 사용됩니다. 화면에 보이는 레이블과 읽기가 일치하고, 문구를 이중 관리하지 않아도 됩니다.⁶¹²

Label을 둘 수 없는 경우에는 AccessibleName을 명시적으로 설정합니다. 더불어 보충 설명이 필요하면 AccessibleDescription, 역할이 외관과 다를 때는 AccessibleRole도 설정할 수 있습니다.¹³

flowchart TB
    accTitle: WinForms 컨트롤의 이름이 정해지는 방식
    accDescr: Button 등은 Text가 그대로 UIA Name이 되고, TextBox처럼 Text가 Name으로 쓰이지 않는 컨트롤은 직전 탭 순서에 둔 Label의 텍스트가 쓰이며, Label을 둘 수 없으면 AccessibleName을 명시적으로 설정한다
    ctrl["컨트롤"] --> qtext{"Text가 Name이 되는 종류인가?"}
    qtext -->|예| usetext["Text가 그대로 Name이 된다"]
    qtext -->|아니오| qlabel{"직전 탭 순서에 Label이 있는가?"}
    qlabel -->|예| uselabel["Label의 텍스트가 Name으로 쓰인다"]
    qlabel -->|아니오| explicit["AccessibleName을 명시적으로 설정"]

그림 7: WinForms의 Name은 Text, 직전 탭 순서의 Label, AccessibleName 순으로 정하는 법을 고릅니다.

// 아이콘만 있는 도구 모음 버튼: 읽기용 이름을 명시한다
saveToolStripButton.AccessibleName = "덮어쓰기 저장";

// 이미지만 있는 버튼: 이름+보충 설명
btnSearchCustomer.AccessibleName = "고객 검색";
btnSearchCustomer.AccessibleDescription = "고객 코드 또는 성명으로 고객 마스터를 검색합니다";

// Label을 직전 탭 순서에 둘 수 없는 입력란에는 직접 설정한다
txtOrderNo.AccessibleName = "수주 번호";

// 그래프 표시에 쓴 PictureBox: 역할도 실제에 맞춘다
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "월별 수주 건수 그래프";

주의점으로, Visual Studio 속성 창에서 AccessibleName을 한 번 설정한 뒤 지우면 디자이너 파일에 빈 문자열 설정이 남아 기본 이름 해석을 막을 수 있습니다. 디자이너 파일에서 해당 행을 삭제하십시오.⁶

flowchart TB
    accTitle: AccessibleName의 빈 문자열이 남는 문제
    accDescr: 속성 창에서 AccessibleName을 한 번 설정한 뒤 지우면 디자이너 파일에 빈 문자열 설정이 남아 기본 이름 해석을 막으므로, 디자이너 파일에서 해당 행을 삭제해 고친다
    set["AccessibleName을 설정"] --> erase["속성 창에서 지운다"]
    erase --> remain["빈 문자열 설정이 남는다"]
    remain --> block["기본 이름 해석을 막는다"]
    block -.-> fix["디자이너 파일의 해당 행을 삭제"]

그림 8: 속성 창에서 지워도 빈 문자열이 남으므로, 디자이너 파일의 해당 행을 삭제해 고칩니다.

4.2. 수주 입력 화면에서 자주 보는 개선점

당사가 업무 앱에서 실제로 자주 고치는 지점을 체크리스트로 정리합니다.

모두 몇 줄의 수정이지만, 스크린 리더 이용자에게는 「쓸 수 없는 화면」과 「쓸 수 있는 화면」의 갈림이 됩니다.

5. WPF 구현 ── AutomationProperties와 AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

WPF에서는 Button처럼 Content가 문자열인 컨트롤은 그 내용이 UIA Name으로 쓰입니다. 아이콘(Image나 Path)만 있는 버튼은 Name의 재료가 없으므로 AutomationProperties.Name으로 명시하거나, 근처 표시 텍스트가 있으면 AutomationProperties.LabeledBy로 연결합니다.⁷

TextBox에는 중요한 주의가 있습니다. TextBlock은 Text가 Name으로 쓰이지만, TextBox의 Text는 UIA의 Value 속성 쪽으로 공개되고 Name이 되지 않습니다. 입력란에는 표시 레이블의 TextBlock을 LabeledBy로 연결하는 것이 첫 후보입니다. 읽기와 화면 표시가 일치하고, 문구의 이중 관리도 피할 수 있습니다.¹⁴

<!-- 입력란: 표시 레이블을 LabeledBy로 연결한다 -->
<TextBlock x:Name="OrderNoLabel" Text="수주 번호" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- 아이콘만 있는 버튼: 이름을 명시하고, 필요하면 보충도 붙인다 -->
<Button
    AutomationProperties.Name="수주를 확정"
    AutomationProperties.HelpText="입력 중인 수주를 확정하고 재고를 할당합니다">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: WPF 컨트롤의 이름이 정해지는 방식
    accDescr: Content가 문자열인 컨트롤은 그 내용이 Name으로 쓰이고, 그렇지 않으면 근처 표시 레이블을 LabeledBy로 연결하는 것이 첫 후보이며, 그것도 없으면 AutomationProperties.Name을 명시하고, TextBox의 Text는 Name이 아니라 Value 쪽으로 공개된다
    ctrl["컨트롤"] --> qc{"Content가 문자열인가?"}
    qc -->|예| auto["내용이 Name이 된다"]
    qc -->|아니오| ql{"근처에 표시 레이블이 있는가?"}
    ql -->|예| lb["LabeledBy로 연결"]
    ql -->|아니오| nm["Name을 명시 설정"]
    tbx["TextBox의 Text"] -.-> val["Name이 아니라 Value로 공개"]

그림 9: WPF의 Name은 Content의 문자열, LabeledBy, 명시 설정 순으로 정하고, TextBox의 Text는 Name이 되지 않습니다.

Name에 담기지 않는 보충 정보는 AutomationProperties.HelpText로 공개할 수 있습니다.⁷ 또한 AutomationId는 UI 자동 테스트에서 요소 식별에도 쓰는 식별자이므로, 화면 설계 단계에서 명명 규칙을 정해 두면 나중에 효과가 납니다(「Windows 데스크톱 앱의 UI 자동 테스트」에서 자세히 다룹니다).

5.2. 커스텀 컨트롤에는 AutomationPeer

직접 그리는 커스텀 컨트롤은 그대로 두면 UIA 트리에 의미 있는 정보를 공개하지 못합니다. WPF에서는 UIElement 파생 클래스의 OnCreateAutomationPeer를 오버라이드하고 AutomationPeer 파생 클래스를 반환해 이름·종류·패턴을 공개합니다. 기존 컨트롤을 상속한 경우에는 대응하는 Peer(ButtonBase라면 ButtonBaseAutomationPeer)를 상속하면 이미 구현된 동작을 이어받을 수 있습니다.¹⁵

flowchart TB
    accTitle: AutomationPeer에 의한 정보 공개의 구조
    accDescr: 커스텀 컨트롤은 OnCreateAutomationPeer를 오버라이드해 AutomationPeer 파생 클래스를 반환함으로써 이름과 종류와 패턴을 공개하고, 기존 컨트롤을 상속한 경우에는 대응하는 Peer를 상속해 이미 구현된 동작을 이어받는다
    custom["커스텀 컨트롤"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Peer 파생 클래스를 반환"]
    peer --> pub["이름·종류·패턴을 공개"]
    inherit["기존 컨트롤을 상속"] -.-> basepeer["대응하는 Peer를 상속"]
    basepeer -.-> reuse["이미 구현된 동작을 이어받는다"]

그림 10: 커스텀 컨트롤은 OnCreateAutomationPeer로 Peer를 반환해 UIA에 정보를 공개합니다.

// 회선 상태를 색 있는 램프로 자체 그리는 컨트롤의 예
public class StatusLamp : Control
{
    public static readonly DependencyProperty IsOnlineProperty =
        DependencyProperty.Register(nameof(IsOnline), typeof(bool), typeof(StatusLamp),
            new FrameworkPropertyMetadata(false,
                FrameworkPropertyMetadataOptions.AffectsRender, OnIsOnlineChanged));

    public bool IsOnline
    {
        get => (bool)GetValue(IsOnlineProperty);
        set => SetValue(IsOnlineProperty, value);
    }

    internal static string NameFor(bool isOnline)
        => isOnline ? "회선 상태: 온라인" : "회선 상태: 오프라인";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // 값이 바뀐 순간에 UIA의 속성 변경 이벤트를 발행한다. 이것이 없으면,
        // 스크린 리더는 옛 이름을 유지한 채 상태 변화를 알아채지 못한다
        if (UIElementAutomationPeer.FromElement((UIElement)d) is AutomationPeer peer)
        {
            peer.RaisePropertyChangedEvent(
                AutomationElementIdentifiers.NameProperty,
                NameFor((bool)e.OldValue), NameFor((bool)e.NewValue));
        }
    }

    protected override AutomationPeer OnCreateAutomationPeer()
        => new StatusLampAutomationPeer(this);
}

public class StatusLampAutomationPeer : FrameworkElementAutomationPeer
{
    public StatusLampAutomationPeer(StatusLamp owner) : base(owner) { }

    protected override AutomationControlType GetAutomationControlTypeCore()
        => AutomationControlType.Text; // 조작이 없는 상태 표시라면 Text에 해당

    protected override string GetNameCore()
        => StatusLamp.NameFor(((StatusLamp)Owner).IsOnline);
}

이름을 반환하는 것만으로는 부족하고, 바뀐 순간에 이벤트로 알리는 것까지가 Peer의 일입니다. 보조 기술은 값을 다시 가져오는 타이밍을 스스로 갖지 않으므로, 변경 이벤트를 발행하지 않는 구현은 「다시 물었을 때만 올바른」 상태가 되고, 스크린 리더 이용자에게는 상태 변화가 전달되지 않습니다.

sequenceDiagram
    accTitle: 상태 변화를 스크린 리더에 전하는 흐름
    accDescr: 컨트롤 값이 바뀐 순간에 AutomationPeer가 Name의 속성 변경 이벤트를 발행하고, 보조 기술은 스스로 다시 가져오지 않으므로 이벤트가 없으면 옛 이름 그대로 변화를 알아채지 못한다
    participant c as 컨트롤
    participant p as AutomationPeer
    participant s as 스크린 리더
    c->>p: IsOnline 값이 변화
    p->>s: Name의 속성 변경 이벤트를 발행
    s->>s: 새 상태를 읽는다
    Note over s: 이벤트가 없으면 옛 이름 그대로

그림 11: 값의 변화는 AutomationPeer가 변경 이벤트로 알려야 비로소 스크린 리더에 닿습니다.

조작을 가진 커스텀 컨트롤(누를 수 있다, 값을 바꿀 수 있다, 선택할 수 있다)이라면 GetPattern을 오버라이드해 IInvokeProvider나 IRangeValueProvider 같은 패턴 인터페이스를 제공합니다.¹⁵ 핵심은 공통 컨트롤 라이브러리 쪽에서 Peer까지 만들어 두면, 그것을 쓰는 모든 화면이 자동으로 대응 완료가 된다는 점입니다. 이는 9장의 「다른 화면으로의 파급」의 토대가 됩니다.

6. 키보드만으로 모든 기능에 도달할 수 있는가

WCAG 성공 기준 2.1.1(키보드)은 콘텐츠의 모든 기능이 키보드 인터페이스에서 조작 가능하기를 요구합니다.⁸ 스크린 리더 이용자는 원칙적으로 마우스를 쓰지 않으므로, 키보드로 도달할 수 없는 기능은 존재하지 않는 기능과 같습니다. 점검 관점은 다음과 같습니다.

WinForms 접근성 안내에서도, 입력란 직전 탭 순서에 레이블을 둘 것, 사용자가 이동하고 싶은 컨트롤과 메뉴에 액세스 키를 붙일 것이 기본으로 꼽힙니다.¹²

강조하고 싶은 것은, 이것이 「장애인 대응을 위한 추가 비용」이 아니라는 점입니다. 수주 입력 같은 정형 업무에서는, 홈 포지션에서 손을 떼지 않고 입력을 마칠 수 있는지가 곧 오퍼레이터의 처리 건수를 결정합니다. 탭 순서가 흐트러지거나 마우스가 필수인 조작은 모든 사용자의 생산성을 매일 조금씩 깎는 결함입니다. 접근성 대응과 키보드 효율화는 같은 작업의 두 이름에 지나지 않습니다(이용 환경별 우선순위는 「Windows 앱 UX 설계」도 참조하십시오).

flowchart TB
    accTitle: 키보드 정비의 이중 효과
    accDescr: 탭 순서나 액세스 키나 포커스 표시의 정비는 보조 기술 이용자가 기능에 도달할 수 있는 것과 모든 오퍼레이터의 입력 속도라는 두 효과를 동시에 만들고, 마우스로만 쓰는 기능은 존재하지 않는 기능과 같아진다
    seibi["키보드 조작의 정비"] --> a11y["보조 기술 이용자가 쓸 수 있다"]
    seibi --> speed["모든 오퍼레이터의 입력 속도"]
    mouse["마우스 전용 기능"] -.-> none["존재하지 않는 기능과 같다"]

그림 12: 키보드 조작의 정비는 보조 기술 대응과 모든 사용자의 효율화를 동시에 이루고, 마우스 전용 기능은 없는 것과 같아집니다.

7. 색과 대비 ── 4.5:1과 「색에만 의존하지 않기」

7.1. 대비비의 가이드는 4.5:1

WCAG 성공 기준 1.4.3(대비(최소))은 텍스트와 문자 이미지에 적어도 4.5:1, 큰 문자에는 적어도 3:1의 대비비를 요구합니다.⁸ 옅은 회색 글자를 흰 배경에 둔 모던한 디자인은 이 기준을 밑도는 일이 드물지 않습니다. 업무 앱 이용자에는 나이 들며 시력·색각이 변한 사람, 공장처럼 조명 조건이 나쁜 환경에서 쓰는 사람도 포함됩니다. 디자인 확인할 때 대비 검사기로 실측하는 습관을 들이십시오.

7.2. 색만으로 정보를 전하지 않기

성공 기준 1.4.1(색의 사용)은 색이 정보를 전하는 유일한 시각 수단이 되어서는 안 된다는 내용입니다.⁸ 업무 앱의 전형 예는 다음과 같습니다.

• 오류 행을 빨간 글자만으로 나타낸다 → 오류 아이콘과 메시지 열을 함께 둔다
• 필수 항목을 레이블 색만으로 나타낸다 → 「*」나 「필수」 표기를 붙인다
• 상태를 램프 색만으로 나타낸다 → 색+형태 또는 글자(「가동 중」「정지」)로 한다

색각의 다양성을 생각하면, 이것 역시 「특별한 대응」이 아니라 표시 설계의 기본입니다.

flowchart TB
    accTitle: 색에만 의존하지 않는 정보 전달로의 교체
    accDescr: 오류를 빨간 글자만으로 보이는 표시는 오류 아이콘과 메시지 열의 병설로, 필수 항목을 레이블 색만으로 보이는 표시는 필수 표기 추가로, 상태를 램프 색만으로 보이는 표시는 형태나 글자의 병용으로 바꾼다
    err["오류를 빨간 글자만"] --> erra["아이콘과 문구를 함께 둔다"]
    req["필수를 레이블 색만"] --> reqa["필수 표기를 붙인다"]
    lamp["상태를 램프 색만"] --> lampa["색에 형태나 글자를 함께 쓴다"]

그림 13: 색만으로 전하고 있는 전형 예는 아이콘·표기·형태나 글자의 병용으로 바꿉니다.

7.3. 대비 테마(고대비)에 따르기

Windows에는 전경과 배경을 강하게 나눈 배색으로 바꾸는 대비 테마(종래의 고대비)가 있고, 대비비가 대체로 7:1 이상이 되도록 설계된 기본 제공 테마를 사용자가 선택·편집할 수 있습니다.⁹ 앱 측 원칙은 단순합니다. 색을 하드코딩하지 않고 시스템 색을 존중하는 것입니다.

• WinForms: ForeColor/BackColor를 기본값으로 두면 사용자의 배색 설정이 쓰입니다. 따로 색을 입힌 곳은 SystemInformation.HighContrast를 판별해 SystemColors 기반 배색으로 바꾸고, UserPreferenceChanged 이벤트로 설정 변경을 따릅니다.¹²
• WPF/WinUI: SystemColors 계열 리소스를 참조하면 테마 전환을 따릅니다. 자체 브러시로 칠한 곳이 깨짐의 원인이 됩니다.⁹

flowchart TB
    accTitle: 대비 테마에 따르기
    accDescr: 색을 하드코딩한 곳은 대비 테마로 바꾸면 깨지므로 SystemColors 기반 배색으로 바꾸고 설정 변경 이벤트로 따르며, 시스템 색을 참조하면 사용자 배색을 자동으로 따른다
    theme["대비 테마로 전환"] --> qh{"색 지정 방법은?"}
    qh -->|하드코딩| broken["배색이 깨진다"]
    qh -->|시스템 색 참조| ok["사용자 배색을 자동으로 따른다"]
    broken -.-> fix["SystemColors로 전환"]
    fix -.-> ev["설정 변경 이벤트로 따른다"]

그림 14: 색을 하드코딩한 곳만 대비 테마에서 깨지고, 시스템 색을 참조하면 자동으로 따릅니다.

또한 저시력 사용자는 OS 확대율(DPI 스케일링)을 높여 쓰는 경우가 많으므로, 고DPI 대응은 접근성 대응의 일부이기도 합니다. 125%〜200%에서 레이아웃이 깨지는 앱은 이 시점에서 쓸 수 없습니다. 자세한 내용은 「WinForms의 고DPI 대응」「WPF의 고DPI 대응」을 참조하십시오.

8. 검증의 실무 ── Accessibility Insights와 스크린 리더 현장 확인

8.1. Accessibility Insights for Windows

Microsoft는 Windows 앱의 접근성 검증 도구로 Accessibility Insights for Windows를 제공하며, 주로 세 가지 쓰임이 있습니다.¹⁰

• Live Inspect: 요소에 마우스 호버하거나 키보드 포커스하기만 해도 그 UIA 속성(Name, ControlType, 패턴 등)을 확인할 수 있습니다. 「이 버튼의 Name은 무엇인가」를 가장 짧게 보는 수단입니다.
• FastPass: 영향이 큰 접근성 문제를 5분 이내에 검출하는 가벼운 검사입니다. Name 누락처럼 기계적으로 판정할 수 있는 문제를 새 화면마다 가려낼 수 있습니다.
• Troubleshooting: 특정 문제의 진단과 수정을 돕습니다. 검출된 문제에서 이 글에서도 인용하는 프레임워크별 수정 가이드로 바로 따라갈 수 있습니다.

Windows SDK에 포함된 Inspect.exe나 AccEvent로도 UIA 트리와 속성을 확인할 수 있지만, 이들은 레거시 도구라는 위치이고, 지금은 Accessibility Insights로의 이전이 권장됩니다.¹⁰

flowchart TB
    accTitle: Accessibility Insights의 세 가지 쓰임
    accDescr: Accessibility Insights for Windows는 Live Inspect로 UIA 속성 확인, FastPass로 영향이 큰 문제의 가벼운 검사, Troubleshooting으로 문제 진단과 수정 지원을 제공하며, Inspect.exe 등 레거시 도구에서는 이전이 권장된다
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["UIA 속성을 확인"]
    fast --> fastf["영향이 큰 문제를 검출"]
    ts --> tsf["진단과 수정을 지원"]
    legacy["Inspect.exe 등"] -.->|이전 권장| ai

그림 15: Accessibility Insights는 확인·검출·진단의 세 쓰임을 가지며, 레거시 도구의 이전 대상이 됩니다.

8.2. 스크린 리더로 현장 확인

도구의 자동 검사가 검출할 수 있는 것은 기계적으로 판정할 수 있는 문제뿐입니다. 마지막에는 반드시 스크린 리더로 실제 업무 조작을 한 바퀴 돌리십시오. Windows 기본 제공 내레이터는 Ctrl+Windows 키+Enter로 바로 시작할 수 있고, NVDA는 무료로 도입할 수 있습니다.¹¹ 확인의 요령은 화면을 보지 않고(또는 디스플레이를 끄고) 읽기만 의지해 「수주 1건을 입력하고 확정한다」 같은 실제 작업을 마칠 수 있는지 시험하는 것입니다. 이름이 붙어 있어도 읽기 순서가 뒤죽박죽이거나, 포커스가 모달 밖으로 빠져나가는 문제는 현장에서만 찾습니다.

flowchart TB
    accTitle: 도구 검증과 현장 확인의 조합
    accDescr: FastPass 등 자동 검사가 검출할 수 있는 것은 기계적으로 판정할 수 있는 문제뿐이며, 나머지는 스크린 리더로 실제 업무 조작을 한 바퀴 돌리며 읽기 순서나 포커스 문제를 현장에서 찾는다
    tool["도구의 자동 검사"] --> kikai["기계적으로 판정할 수 있는 문제"]
    tool -.-> nokori["검출하지 못하는 문제가 남는다"]
    nokori --> sr["스크린 리더로 현장 확인"]
    sr --> task["업무 조작을 한 바퀴 돈다"]
    task --> mieru["읽기 순서나 포커스 문제"]

그림 16: 자동 검사로 기계적 문제를 가려내고, 나머지는 스크린 리더 현장 확인으로 찾습니다.

8.3. 개발 흐름에 넣기와 UI 자동 테스트와의 시너지

검증을 특정인에게만 맡기지 않으려면, 새 화면 리뷰 항목에 다음 체크리스트를 넣는 것을 권합니다.

그리고 하나 더. FlaUI 등에 의한 UI 자동 테스트는 스크린 리더와 같은 UIA를 기반으로 합니다. 접근성을 위해 갖춘 Name과 패턴은 테스트 코드의 부품이 되고, 테스트용으로 설계한 AutomationId는 Live Inspect 디버그를 쉽게 합니다. 반대로 UIA 트리에 나타나지 않는 UI는 테스트에서도 보조 기술에서도 보이지 않습니다. 접근성과 테스트 용이성은 같은 투자의 양면입니다(「Windows 데스크톱 앱의 UI 자동 테스트」).

flowchart TB
    accTitle: 접근성과 UI 자동 테스트의 시너지
    accDescr: 스크린 리더와 FlaUI 등 UI 자동 테스트는 같은 UIA를 기반으로 하므로 갖춘 Name이나 패턴은 양쪽에서 쓸 수 있고, UIA 트리에 나타나지 않는 UI는 어느 쪽에서도 보이지 않는다
    uia["UIA 트리의 정비"] --> sr["스크린 리더가 읽는다"]
    uia --> test["UI 자동 테스트에서 쓴다"]
    sr -.-> both["같은 투자의 양면"]
    test -.-> both
    hidden["UIA에 나타나지 않는 UI"] -.-> invisible["어느 쪽에서도 보이지 않는다"]

그림 17: 같은 UIA 기반 위에 있으므로, UIA 트리 정비는 보조 기술과 UI 자동 테스트 모두에 효과가 있습니다.

9. 우선순위 정하기 ── 전 화면을 한 번에 고치지 않기

수백 화면이 있는 핵심 시스템을 한꺼번에 고치는 일은 비용으로도 품질로도 비현실적입니다. 당사가 권하는 진행은 다음 3단 구성입니다.

1. 그 이용자가 업무에서 쓰는 화면부터 고친다. 합리적 배려는 당사자의 신청에 개별적으로 응하는 과정입니다.¹ 먼저 본인에게 실제 업무를 스크린 리더로 조작하게 하고, 막히는 지점을 함께 특정하십시오. 많은 경우 일상 업무에서 쓰는 화면은 몇 개〜십수 개로 좁혀지고, 그중 치명적인 문제(이름 없는 버튼, 키보드로 누를 수 없는 확정 버튼)는 며칠 단위의 수정으로 해소할 수 있습니다.
2. 신규 개발분은 표준으로 대응한다. 8장의 체크리스트를 완료 정의(Definition of Done)에 넣고, 새 화면은 처음부터 대응된 상태로 만듭니다. 나중에 얹는 수정과 달리, 설계 때 넣는 분의 비용 증가는 작습니다.
3. 공통 컨트롤 수정으로 다른 화면에 파급한다. 사내 공통 검색 대화 상자, 그리드, 날짜 입력 같은 공통 부품에 AccessibleName 기본값이나 AutomationPeer를 구현하면, 그것을 쓰는 모든 화면에 한꺼번에 효과가 납니다. 개별 화면을 하나씩 만지는 것보다 훨씬 비용 대비 효과가 높은 수단입니다.

flowchart TB
    accTitle: 수정 우선순위의 3단 구성
    accDescr: 이용자가 업무에서 쓰는 화면부터 고치고, 신규 개발분은 체크리스트로 표준 대응하며, 공통 컨트롤 수정으로 모든 화면에 파급한다
    s1["1. 이용자가 쓰는 화면부터 고친다"] --> s2["2. 신규분은 표준으로 대응"] --> s3["3. 공통 컨트롤로 파급"]
    s3 -.-> all["그것을 쓰는 모든 화면에 한꺼번에 효과가 난다"]

그림 18: 전 화면의 일제 수정이 아니라, 쓰는 화면·신규분·공통 부품의 3단 구성으로 진행합니다.

그리고 기술 대응만큼 중요한 것이 대화의 기록입니다. 합리적 배려는 「대화하며 개별적으로 조정하는」 과정이지, 모든 요청에 완전 대응하는 것이 아닙니다. 부담이 지나친 수정에 대해 대체 수단(해당 업무를 다른 화면에서 한다, CSV 출력을 마련한다, 운영으로 커버한다)을 본인과 검토해 합의하는 일도 건설적 대화의 정당한 귀결입니다.¹ 무엇을 요청받았고, 무엇을 대응했으며, 무엇을 대체 수단으로 했는지를 기록해 두는 일이 조직으로서의 성실함의 증명이 됩니다.

flowchart TB
    accTitle: 건설적 대화와 기록의 흐름
    accDescr: 장애인의 요청에 건설적 대화로 응하고, 대응할 수 있는 수정은 실시하며, 부담이 지나친 수정은 대체 수단을 본인과 검토해 합의하고, 무엇을 요청받았고 무엇을 대응했으며 무엇을 대체 수단으로 했는지를 기록한다
    req["요청"] --> talk["건설적 대화"]
    talk --> q{"부담이 지나친가?"}
    q -->|아니오| kaishu["수정으로 대응"]
    q -->|예| alt["대체 수단을 검토하고 합의"]
    kaishu --> rec["경위를 기록한다"]
    alt --> rec

그림 19: 건설적 대화에서는 수정인지 대체 수단인지를 본인과 합의하고, 그 경위를 기록으로 남깁니다.

10. 정리

• 2024년 4월 시행된 개정 장애인차별해소법으로 사업자에게도 합리적 배려 제공이 의무화되었습니다. 고용 분야는 장애인고용촉진법에 따라 2016년부터 사업주 의무입니다. 앱의 사전 수정은 「환경 정비」(노력 의무)에 해당하고, 진행해 둘수록 개별 대응이 가벼워집니다.
• 기술 기준은 WCAG(JIS X 8341-3:2016)에 모이고, WCAG2ICT에 의해 데스크톱 앱에도 같은 생각을 적용할 수 있습니다.
• 스크린 리더는 UI Automation을 통해 앱을 읽습니다. UIA 트리·속성(Name/ControlType/AutomationId)·컨트롤 패턴의 3점 세트가 토대입니다.
• 최우선은 Name입니다. WinForms는 AccessibleName과 Label·탭 순서 연결, WPF는 AutomationProperties.Name/LabeledBy, 커스텀 컨트롤은 AutomationPeer로 대응합니다.
• 키보드만으로 모든 기능에 도달할 수 있는 것은 WCAG 성공 기준인 동시에 모든 오퍼레이터의 생산성입니다. 탭 순서·액세스 키·포커스 표시를 갖추십시오.
• 대비비 4.5:1, 색에만 의존하지 않기, 대비 테마에서는 시스템 색을 존중, 이 세 가지가 색의 기본입니다.
• 검증은 Accessibility Insights의 FastPass+Live Inspect와 내레이터/NVDA 현장 확인을 조합하고, 새 화면 체크리스트로 개발 흐름에 넣습니다.
• 전 화면을 한 번에 고치지 않고, 이용자가 쓰는 화면→신규분의 표준 대응→공통 컨트롤의 파급 순으로 진행합니다. 합리적 배려는 대화의 과정이며, 경위 기록이 조직을 지킵니다.

첫걸음으로 권하는 것은, 자사 주력 화면을 하나 골라 Accessibility Insights for Windows의 FastPass를 실행한 뒤 Tab 키만으로 업무를 한 바퀴 돌아보는 것입니다. 30분이면 우리 앱의 현재 위치가 놀랄 만큼 구체적으로 보입니다.

관련 글

• Windows 데스크톱 앱의 UI 자동 테스트 ── UI Automation의 구조와 FlaUI로 만드는 잘 깨지지 않는 테스트
• Windows 앱 UX 설계 - 이용 환경별 우선순위
• WinForms의 고DPI 대응 ── 4K 모니터에서 흐려지고 깨지는 원인과 현실적인 대처
• WPF의 고DPI 대응 ── 「DPI에 강할 텐데」도 흐려지고 번지는 원인과 대처
• 왜 고무라소프트는 디지털청 디자인 시스템으로 HP를 만드는가 ── 저렴함과 품질은 양립할 수 있다
• 일본어 폰트와 문자의 함정 ── JIS2004·이체자 셀렉터·외자를 업무 앱에서 어떻게 다루는가

관련 상담 영역

합동회사 고무라소프트에서는 WinForms/WPF 업무 앱의 접근성 수정(스크린 리더 대응, 키보드 조작 정비, 대비 테마 대응), 공통 컨트롤에 AutomationPeer 구현, Accessibility Insights를 사용한 현황 진단과 우선순위 정하기 상담을 다룹니다. 「직원이 스크린 리더로 우리 앱을 쓸 수 있는지 확인하고 싶다」는 단계부터여도 됩니다.

• Windows 앱 개발
• 기술 상담·설계 리뷰
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

업무 앱의 접근성 대응은 법률로 의무인가요?

2021년 개정 장애인차별해소법이 2024년 4월 1일 시행되어, 사업자에게도 장애인에 대한 합리적 배려 제공이 의무화되었습니다. 합리적 배려는 장애인이 신청했을 때 부담이 지나치지 않은 범위에서 개별 장벽을 제거하는 대응이고, 앱을 미리 쓰기 쉽게 고쳐 두는 일은 「환경 정비」라는 노력 의무입니다. 고용 분야는 장애인고용촉진법의 대상이며, 2016년 4월 시행 개정으로 사업주에게 합리적 배려 제공이 의무입니다. 「직원이 업무 앱을 쓸 수 없다」는 장면은 이전부터 의무 영역입니다. 어디까지 할지는 개별 상황에 따르므로, 내각부·후생노동성 1차 정보를 확인한 뒤 당사자와의 대화로 정합니다.

스크린 리더는 Windows 데스크톱 앱을 어떻게 읽나요?

내레이터나 NVDA 같은 스크린 리더는 UI Automation(UIA)이라는 접근성 기반을 통해 앱 UI를 읽습니다. 앱은 화면 요소를 UIA 트리로 공개하고, 각 요소는 Name(목적), ControlType(종류) 같은 속성과 Invoke(누르기), Value(값) 같은 컨트롤 패턴을 가집니다. 스크린 리더는 이 정보를 「수주 확정 버튼」처럼 읽고 패턴으로 조작합니다. WinForms·WPF 표준 컨트롤은 이 기반을 처음부터 갖추므로, 개발자의 주된 일은 Name을 비우지 않고, 키보드로 조작 가능하게 하며, 커스텀 컨트롤에 정보를 구현하는 것입니다.

기존 WinForms 앱에서는 무엇부터 하면 되나요?

먼저 Accessibility Insights for Windows의 FastPass를 대상 화면에 실행해 Name이 비어 있는 컨트롤과 탭 순서 문제를 가려내는 길이 빠릅니다. 수정은 아이콘만 있는 버튼에 AccessibleName 설정, 입력란 직전 탭 순서에 Label을 두는 연결, 보이는 배치와 맞는 TabIndex 정리부터 시작합니다. 이어서 내레이터나 NVDA를 켜고 화면을 보지 않은 채 실제 업무 조작을 한 바퀴 돌며 막히는 지점을 확인하십시오. 전 화면을 한 번에 고칠 필요는 없고, 실제로 쓰는 사람이 있는 화면부터 손대고 신규 화면은 체크리스트로 표준 대응하는 편이 현실적입니다.

고대비(대비 테마) 대응에서는 무엇을 하면 되나요?

기본은 색을 하드코딩하지 않고 시스템 색을 존중하는 것입니다. WinForms라면 ForeColor/BackColor를 기본값으로 두거나 SystemColors를 쓰고, SystemInformation.HighContrast로 상태를 판별한 뒤 UserPreferenceChanged 이벤트로 전환을 따릅니다. WPF나 WinUI도 SystemColors 계열 리소스를 참조하면 테마 전환을 자동으로 따릅니다. 오류를 빨간색만으로 알리는 식의 「색에만 의존한」 전달은 멈추고, 아이콘이나 문구를 함께 쓰십시오. 일반 테마에서도 텍스트 대비비 4.5:1 이상이라는 WCAG 기준을 가이드로 삼으면, 조명이 나쁜 현장이나 고령 사용자에게도 읽기 쉬워집니다.

접근성 대응은 UI 자동 테스트에도 도움이 되나요?

도움이 됩니다. FlaUI 같은 UI 자동 테스트 도구는 스크린 리더와 같은 UI Automation을 기반으로 하기 때문입니다. 접근성 대응으로 갖춘 Name, ControlType, 컨트롤 패턴은 테스트 코드에서 그대로 쓸 수 있고, 테스트용으로 설계한 AutomationId는 요소 식별을 안정시킵니다. 반대로 UIA 트리에 나타나지 않는 자체 그리기 UI는 스크린 리더에도 테스트에도 보이지 않습니다. 접근성과 자동 테스트는 같은 기반에 대한 투자이므로, 한쪽을 갖추면 다른 쪽 비용도 내려갑니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.