github·2026년 6월 9일·3분 읽기큐레이션 요약

일회성 프롬프트에서 워크플로로: GitHub Copilot CLI에서 커스텀 에이전트를 사용하는 방법

GitHub Copilot CLI의 커스텀 에이전트는 반복적인 터미널 작업과 팀의 개발 규칙을 Markdown 기반 워크플로로 표준화하는 기능이다. 저장소에 에이전트 프로필을 두면 팀의 도구, 코딩·보안·접근성 기준, 출력 형식을 버전 관리하며 CLI·IDE·GitHub 전반에서 일관되게 사용할 수 있다. 따라서 일회성 프롬프트를 반복하는 대신 검토 가능하고 재사용 가능한 전문 에이전트를 구축할 수 있다. ## 커스텀 에이전트의 개념 - 커스텀 에이전트는 특정 작업에 특화된 Copilot 에이전트다. - Markdown 파일인 에이전트 프로필에 다음 내용을 정의한다. - 에이전트의 역할과 전문 영역 - 사용할 수 있는 도구 - 따라야 할 개발·보안·접근성 기준 - 실행 범위와 안전장치 - 결과물의 형식 - 일반적인 코드 정리 에이전트와 달리, 팀의 포맷 규칙·접근성 표준·리뷰 절차·보안 요구사항을 매번 동일하게 적용할 수 있다. - 프로필이 저장소에 포함되므로 코드처럼 리뷰·수정·공유·버전 관리가 가능하다. ## 에이전트 프로필 구성 프로필은 YAML frontmatter와 지침 본문으로 구성된다. - `name`: 에이전트 이름 - `description`: 에이전트의 목적과 역할 - `model`: 사용할 Copilot 모델 - `tools`: 코드베이스 검색, 파일 수정, 테스트 실행, 터미널, 웹 요청 등 허용할 도구 - 본문 지침: - 에이전트의 전문성 - 작업 절차 - 출력 형식 - 금지 사항과 안전 규칙 예를 들어 접근성 전문가 에이전트는 WCAG 2.1/2.2의 A·AA·AAA 등급을 기준으로 웹 UI를 검토하고, 디자인·개발·QA에 적용 가능한 실무 지침을 제공하도록 설정할 수 있다. ## GitHub Copilot CLI에서 사용하는 방법 - 터미널에서 GitHub Copilot CLI를 실행한다. - `/agent` 슬래시 명령을 사용해 원하는 커스텀 에이전트를 선택한다. - 대상 저장소의 `.github/agents` 디렉터리에 프로필을 만든다. - 파일 확장자는 `.agent.md`를 사용한다. 예: - `.github/agents/accessibility.agent.md` - `.github/agents/security-audit.agent.md` - CLI는 정의된 도구와 지침에 따라 스크립트 실행, API 호출, 저장소 분석 등을 반복 가능한 방식으로 수행한다. ## 자동화할 수 있는 보안 감사 글에서는 보안 점검을 대표적인 커스텀 에이전트 활용 사례로 제시한다. - 여러 저장소에서 팀의 표준 보안 도구를 실행한다. - `gitleaks`: 비밀·자격 증명 탐지 - `trivy`: 파일 시스템 및 컨테이너 취약점 검사 - `semgrep`: 정적 분석 - `gh`: GitHub 설정 및 의존성 검토 - `jq`, `git`: 결과 처리와 저장소 작업 - 결과를 `Critical`, `High`, `Medium`, `Low` 심각도로 분류한다. - 담당자와 다음 조치를 포함한 PR용 체크리스트로 출력한다. - 저장소에 이미 존재하는 설정 파일을 우선 사용한다. - `.semgrep.yml` - `.trivyignore` - `.gitleaks.toml` - 도구가 설치되지 않은 경우 결과를 추측하지 않고 “검사 범위의 공백”으로 기록한다. - 토큰이나 자격 증명 등 민감한 정보는 출력에서 마스킹한다. - `CODEOWNERS`가 없으면 경로별 기본 담당 팀을 매핑해 후속 조치를 명확히 한다. ## 커스텀 에이전트의 장점 - 반복 작업을 자동화해 명령어 재실행과 컨텍스트 재설명을 줄인다. - 팀 표준을 프롬프트가 아닌 저장소 파일로 관리할 수 있다. - 결과 형식과 품질 기준이 일관된다. - CLI에서 시작한 작업을 IDE와 GitHub의 리뷰·PR 흐름으로 자연스럽게 연결할 수 있다. - 에이전트 설정 자체를 코드 리뷰 대상으로 삼아 변경 이력과 책임 소재를 남길 수 있다. 반복적으로 수행하는 보안 검사, 접근성 검토, 테스트 실행, 로그 분석 같은 작업부터 `.github/agents`에 에이전트로 정의하는 것이 좋다. 특히 허용 도구, 민감 정보 처리, 실패 시 동작, 결과 형식을 명확히 작성하면 Copilot CLI를 단순한 명령어 생성기가 아니라 팀 표준을 실행하는 재사용 가능한 워크플로 엔진으로 활용할 수 있다.

원문 읽기(새 탭에서 열림)

web-accessibilitymarkdownyamlgithub-copilot-cli+4

github·2026년 3월 12일·4분 읽기큐레이션 요약

접근성을 위한 지속적인 AI: GitHub이 피드백을 포용으로 전환하는 방법

GitHub는 접근성 피드백이 여러 팀과 채널에 흩어져 처리되지 못하던 문제를 해결하기 위해, 피드백을 지속적으로 수집·분류·추적하는 AI 기반 워크플로를 구축했다. GitHub Actions, GitHub Copilot, GitHub Models를 결합해 반복적인 분석과 라우팅은 자동화하되, 우선순위와 해결 판단은 사람이 맡는다. 그 결과 접근성 문제를 일회성 감사가 아니라 지속적으로 개선되는 운영 시스템으로 전환했다. ## 접근성 피드백이 기존 방식에서 겪은 문제 - 접근성 문제는 내비게이션, 인증, 설정, 공통 컴포넌트 등 여러 영역에 걸쳐 발생해 단일 팀이 소유하기 어렵다. - 피드백이 여러 백로그와 버그 목록에 분산되면서 담당자가 정해지지 않거나 장기간 방치됐다. - 사용자가 반복해서 진행 상황을 문의해야 했고, 개선 사항이 막연한 “2단계 작업”으로 미뤄지는 경우가 많았다. - 따라서 단순한 버그 관리가 아니라, 접수부터 해결과 후속 안내까지 연결하는 조정 체계가 필요했다. ## Continuous AI: 접근성을 살아 있는 시스템으로 관리 - GitHub가 말하는 Continuous AI는 단일 제품이나 일회성 자동 검사 도구가 아니다. - 자동화, 인공지능, 사람의 전문성을 결합해 소프트웨어 개발 과정에 접근성을 지속적으로 포함시키는 방법론이다. - 코드 스캐너만으로는 실제 사용자가 겪는 장벽을 충분히 발견하기 어렵기 때문에, 사용자와 고객의 경험을 중심 데이터로 삼는다. - 피드백을 명확한 구조의 데이터로 바꾸고, 적절한 팀에 전달하며, 구현 가능한 이슈로 발전시키는 것이 핵심이다. - 이는 2025년 GAAD pledge의 방향인 오픈소스 생태계 전반의 접근성 개선과도 연결된다. ## 사용자와 조직 구성원을 위한 설계 시스템은 세 가지 주요 사용자를 기준으로 설계됐다. - **이슈 제출자** - 커뮤니티 관리자, 지원 담당자, 영업 담당자가 사용자를 대신해 문제를 등록한다. - 이들이 반드시 접근성 전문가일 필요는 없으므로, 입력 과정에서 접근성 개념과 필요한 정보를 안내해야 한다. - **접근성·서비스 팀** - 엔지니어와 디자이너가 재현 단계, WCAG 기준, 심각도, 담당 팀 등 실행 가능한 정보를 받아야 한다. - **프로그램·제품 관리자** - 문제 유형별 현황, 반복되는 추세, 해결 진행률을 파악해 리소스와 우선순위를 결정해야 한다. - 이를 위해 피드백을 단순 티켓이 아니라 파이프라인을 따라 흐르는 데이터로 취급하고, 변화에 맞춰 확장 가능한 구조를 선택했다. ## 이벤트 기반 피드백 워크플로 - 각 단계가 GitHub Action을 실행하는 이벤트 기반 구조로 설계됐다. - 이슈가 생성되면 GitHub Models API를 통해 GitHub Copilot이 피드백을 분석한다. - 상태가 변경되면 다음 담당 팀으로 자동 인계된다. - 문제가 해결되면 최초 제출자에게 후속 안내를 보내 사용자와의 소통을 마무리한다. - 모든 Action은 수동 실행하거나 재실행할 수 있어, 자동화가 처리하지 못하는 경우 사람이 언제든 개입할 수 있다. - 전체 흐름은 다음 일곱 단계로 구성된다. - 접수(Actioning intake) - Copilot 분석 - 제출자 검토 - 접근성 팀 검토 - 링크 감사 - 사용자와의 마무리 소통 - 개선 및 프롬프트 업데이트 - 제출자 검토에서 Copilot 분석을 다시 실행하거나, 마무리 단계에서 접근성 팀 검토로 되돌아가는 식의 피드백 루프도 포함된다. - 2024년 중반에는 이 시스템을 주로 직접 구축했지만, 현재는 자연어로 GitHub Actions를 생성할 수 있는 Agentic Workflows를 이용하면 유사한 시스템을 더 빠르게 만들 수 있다. ## 다양한 채널에서의 접수와 표준화 - 접근성 피드백은 지원 티켓, 소셜 미디어, 이메일, 직접 연락 등 다양한 경로에서 들어온다. - 현재 약 90%는 GitHub 접근성 Discussion 게시판을 통해 접수된다. - 공개 게시판에서는 다른 사용자가 문제를 확인하거나 추가 맥락과 우회 방법을 제공할 수 있어, 일반 지원 티켓보다 풍부한 정보가 모이는 장점이 있다. - 모든 피드백에는 영업일 기준 5일 이내에 응답한다. - 즉시 조치할 수 없는 내용도 관련 자료나 도움을 받을 수 있는 경로를 안내해 응답이 끊기지 않도록 한다. - 내부 팀의 조치가 필요한 경우 담당자가 사용자 보고 내용, 출처, 관련 컴포넌트를 담은 전용 접근성 피드백 이슈 템플릿으로 추적 이슈를 만든다. - 이슈 템플릿은 접수 정보를 표준화해 초기 맥락이 트리아지 과정에서 사라지는 것을 방지한다. ## 운영 방식에서 얻는 시사점 - AI는 접근성 문제의 최종 판단자라기보다 반복적인 분류·요약·전달을 담당하는 보조 수단으로 사용된다. - 실제 해결 여부, 우선순위, 담당 지정에는 사람의 전문성과 판단이 계속 필요하다. - 효과적인 자동화의 전제는 AI 모델 자체가 아니라, 먼저 피드백 채널을 정리하고 입력 형식을 표준화하는 일이다. - 접근성 문제를 개별 팀의 선택적 업무가 아니라 지속적으로 측정하고 개선해야 하는 제품 운영 데이터로 다뤄야 한다. 실무적으로는 먼저 접근성 피드백을 한곳으로 모으고, 재현 단계·영향 범위·WCAG 기준·심각도·소유 팀을 포함한 템플릿을 마련하는 것이 좋다. 그 기반 위에서 AI와 워크플로 자동화를 도입해야 자동 분류가 실제 해결과 사용자 후속 안내로 이어질 수 있다.

원문 읽기(새 탭에서 열림)

web-accessibilitygithub-copilotGitHub Actionsagentic-workflows+3

woowahan·2025년 12월 5일원문

잃어버린 접근성을 찾아서 | 우아한형제들 기술블로그 (새 탭에서 열림)

웹 접근성은 단순히 점수를 높이는 기술적 과제가 아니라, 모든 사용자가 소외 없이 서비스를 이용할 수 있도록 보장하는 보편성의 가치를 실현하는 작업입니다. 우아한형제들 기술 블로그에서는 스크린 리더 사용자가 겪는 실질적인 불편함을 해결하기 위해 탐색 단위 구조화, 텍스트 통합, 상호작용 요소의 역할 구체화를 진행했습니다. 이를 통해 사용자 탐색 피로도를 획기적으로 낮추고 서비스의 본질적인 사용성을 회복하는 성과를 거두었습니다. ### 랜드마크와 머리말을 활용한 탐색 구조화 * **단위 탐색 기능 활성화**: 스크린 리더의 '로터(iOS)'나 '단위 탐색(Android)' 기능을 활용할 수 있도록 페이지를 의미 있는 섹션으로 나누고 적절한 머리말(Heading)을 배치했습니다. * **섹션 컴포넌트화**: `section` 태그와 `h1-h6` 태그, 그리고 이를 연결하는 `aria-labelledby` 속성을 조합한 재사용 가능 컴포넌트를 만들어 페이지 전체에 일관된 랜드마크 구조를 적용했습니다. * **목록 역할 명시**: CSS에서 `list-style: none`을 적용할 경우 VoiceOver가 목록으로 인식하지 못하는 문제를 해결하기 위해 `role="list"`를 명시적으로 선언했습니다. ### 파편화된 텍스트 통합과 발화 최적화 * **불필요한 스와이프 제거**: 스타일링을 위해 "990"과 "원"처럼 분리되어 있던 텍스트를 템플릿 리터럴을 통해 하나의 문자열로 결합하여 스크린 리더가 한 번에 읽도록 개선했습니다. * **스크린 리더 전용 레이어 활용**: 디자인 제약으로 태그를 분리해야만 하는 경우, 시각적 요소에는 `aria-hidden="true"`를 설정하고 보이지 않는 별도 요소에 통합된 텍스트를 담아 제공했습니다. * **크로스 플랫폼 대응**: `span`이나 `div` 같은 일반 컨테이너에 `aria-label`을 쓰면 iOS VoiceOver가 이를 무시하는 특성을 고려하여, 다양한 OS 환경에서 일관되게 읽히는 방식을 채택했습니다. ### 상호작용 요소의 목적과 맥락 명확화 * **모호한 버튼 레이블 개선**: "전체 보기", "자세히"와 같이 목적이 불분명한 버튼에 `aria-label`을 추가하여 "배달팁 자세히 보기"처럼 구체적인 동작 맥락을 제공했습니다. * **사용자 흐름 단축**: 300번 이상의 스와이프가 필요했던 비효율적인 탐색 구조를 개선하여, 사용자가 원하는 정보를 빠르게 찾고 구매하기 버튼까지 도달하는 시간을 대폭 단축했습니다. 진정한 의미의 접근성 개선은 Lighthouse 점수 100점에 안주하는 것이 아니라, 개발자가 직접 스크린 리더를 켜고 사용자의 시점에서 서비스를 탐색해 보는 것에서 시작됩니다. 자동화 도구가 잡아내지 못하는 '맥락의 단절'을 찾아내고, 의미 있는 구조(Semantic)와 구체적인 설명(Labeling)을 더할 때 비로소 모두를 위한 서비스를 완성할 수 있습니다.

web-accessibilityfrontendariasemantic-html+2

figma·2025년 8월 3일·3분 읽기큐레이션 요약

디자인에 마우스가 필요

Figma는 마우스 없이도 디자인 작업을 수행할 수 있도록 키보드 접근성 기능을 대폭 강화했다. 이제 키보드만으로 캔버스 이동, 객체 삽입, 정밀한 선택이 가능하며, 스크린 리더가 작업 내용을 읽어줘 사용자가 현재 위치와 상태를 파악하기 쉬워졌다. 이는 키보드나 스크린 리더를 주로 사용하는 디자이너도 디자인 프로세스에 온전히 참여할 수 있도록 장벽을 낮추려는 업데이트다. ## 키보드만으로 이어지는 디자인 작업 - 기존에는 키보드만 사용할 경우 프레임 간 이동, 컴포넌트 선택, 새 요소 추가가 어려웠다. - 캔버스 상단에 갇히거나 잘못된 영역으로 확대·축소되는 등 작업 흐름이 끊기는 문제가 있었다. - 이번 업데이트는 기존 단축키에 더해 패닝, 삽입, 선택 기능을 보완해 디자인 스프린트, 공동 작업, 디자인 리뷰까지 마우스 없이 수행할 수 있게 한다. - 기능 개발 과정에서 키보드와 스크린 리더를 사용하는 디자이너 및 알파 사용자들의 피드백을 반영했다. ## 방향키 기반 캔버스 이동 - 방향키로 캔버스를 상하좌우로 이동할 수 있다. - `Shift` 키를 함께 사용하면 더 빠르게 이동하거나 스크롤할 수 있다. - 새 키보드 단축키를 통해 확대·축소를 세밀하게 조정할 수 있다. - 이동 도구와 손 도구에도 키보드로 접근할 수 있어 캔버스 탐색의 유연성이 높아졌다. ## 키보드로 객체 삽입과 배치 - 도형, 텍스트 등 대부분의 객체 유형을 키보드만으로 캔버스에 추가할 수 있다. - 프레임은 키보드 단축키와 십자선 형태의 안내 화면을 이용해 원하는 위치에 삽입할 수 있다. - `Enter` 키를 사용하면 화면 중앙에 텍스트를 배치할 수 있다. - 마우스 포인터 없이도 삽입 위치를 확인하고 객체를 생성할 수 있다. ## 키보드 기반 객체 선택 - 새로운 키보드 박스 선택 도구로 캔버스의 객체를 선택할 수 있다. - 방향키로 분홍색 커서를 이동해 객체 위에 놓은 뒤 `Enter`를 누르면 해당 객체를 선택한다. - 객체를 하나씩 선택하거나 선택 상자를 이용해 여러 객체를 동시에 선택할 수 있다. - 선택한 객체의 위치 조정 역시 키보드 중심으로 처리할 수 있다. ## 스크린 리더와 포용적인 디자인 - 사용자가 수행하는 작업을 스크린 리더가 읽어주므로 현재 상태와 위치를 파악하기 쉬워졌다. - 이번 기능은 단순히 Figma 사용성을 개선하는 것을 넘어, 더 많은 사람이 창작 과정에 참여하도록 하는 데 목적이 있다. - Figma는 색상 선택기의 대비 검사기를 통해 텍스트와 그래픽이 WCAG 기준을 충족하는지 확인할 수 있도록 지원한다. - 디자인에서 의미 있는 HTML 시맨틱 태그를 지정할 수 있어 스크린 리더를 지원하는 제품 설계에도 활용할 수 있다. - 접근성을 일회성 점검 항목이 아니라 지속적으로 개선해야 할 제품 개발 원칙으로 보고 있다. 마우스 사용이 어렵거나 키보드·스크린 리더를 선호하는 사용자는 Figma의 키보드 단축키와 스크린 리더 지원을 활성화해 작업 흐름을 점검해볼 만하다. 팀 차원에서도 이러한 기능을 활용하면 접근성을 고려한 디자인 협업 환경을 더 쉽게 구축할 수 있다.

원문 읽기(새 탭에서 열림)

web-accessibilityFigmakeyboard-navigationwcag+2

figma·2023년 5월 15일·3분 읽기큐레이션 요약

그잼 스크린 리더

FigJam은 스크린 리더와 키보드만으로 캔버스의 콘텐츠를 읽고 만들 수 있도록 지원을 공식 출시했다. 사용자는 캔버스와 메뉴 사이를 이동하며 파일 구조, 텍스트가 포함된 도형, 스티키, 표, 이미지 대체 텍스트를 확인·편집할 수 있다. 다만 커서 채팅, 투표, 위젯, 자유형 벡터 편집 등 일부 기능은 아직 지원되지 않으며, Figma는 실제 사용자 피드백을 바탕으로 접근성을 계속 확장할 계획이다. ## 협업 도구 전체를 위한 접근성 - FigJam은 아이디어를 정리하고 의사결정을 맞추는 협업 중심 도구이므로, 팀 구성원 모두가 참여할 수 있어야 한다는 판단에서 접근성 개선 대상이 됐다. - Figma 프로토타입에 스크린 리더 지원을 도입한 뒤, 다음 단계로 FigJam을 선택했다. - 정밀한 디자인 도구인 Figma보다 FigJam은 기능이 상대적으로 표면에 드러나 있어, 접근 가능한 UI 패턴을 실험하기에 적합했다. ## 스크린 리더로 가능한 작업 - 스크린 리더 및 키보드 사용자는 캔버스의 여러 요소와 메뉴·화면 사이에서 포커스를 이동할 수 있다. - 다음 콘텐츠를 읽고 생성·편집할 수 있다. - FigJam 파일의 구조 - 텍스트가 포함된 도형 - 스티키 노트 - 표 - 이미지의 대체 텍스트 - 캔버스에서는 콘텐츠를 문자 그대로 읽는 것뿐 아니라, 계층 구조와 캔버스 내 위치를 통해 맥락도 파악해야 한다. - 아직 지원되지 않는 기능에는 커서 채팅 탐색, 스탬프 조정, 투표, 이모트 휠, 위젯 상호작용, 선·하이라이트·와시 테이프·마커 같은 자유형 벡터 노드 편집이 포함된다. ## ARIA 표준만으로는 부족했던 캔버스 접근성 - WAI-ARIA는 웹 콘텐츠와 애플리케이션의 접근성과 상호운용성을 높이기 위한 기술 명세다. - 일반적인 웹사이트나 단순한 위젯과 달리, Figma·FigJam 같은 캔버스 기반 도구에는 참고할 만한 접근성 패턴과 모범 사례가 충분하지 않았다. - 따라서 팀은 처음부터 정해진 구현 방식을 따르기보다, 실제로 도구를 사용할 수 있게 만드는 핵심 기능이 무엇인지 먼저 정의했다. - 접근성 테스트 기관 Fable과 협력해 보조공학 사용자들의 테스트와 피드백을 수집했다. - 일부 베타 테스터는 디지털 화이트보드나 실제 화이트보드 경험도 없었기 때문에, 기존 도구의 사용 패턴을 전제로 하지 않고 사용자 여정을 새롭게 설계했다. ## 다양한 키보드와 보조공학 환경 고려 - 스크린 리더 종류, 설정, 보조공학 기술, 국제 키보드 배열에 따라 사용 가능한 조합이 매우 다양하다. - 베타 인터뷰를 통해 팀은 스크린 리더 사용 방식에 대해 지속적으로 새로운 사실을 발견했다. - 이 과정에서 얻은 패턴은 FigJam뿐 아니라 Figma 전반의 접근성 개선에도 활용됐다. - React 컴포넌트에 ARIA 레이블과 태그를 적용하는 등, 코드베이스에 재사용 가능한 접근성 패턴을 구축했다. - 한 번 만들어진 패턴은 다른 엔지니어들도 반복해서 적용할 수 있어 제품 전체의 접근성 향상에 기여한다. ## 단계적 출시와 향후 과제 - 캔버스 기반 협업 도구의 접근성에는 확립된 정답이 부족했기 때문에, 초기 출시 범위를 핵심 사용자 여정 중심으로 정했다. - 제품을 한 번에 완성하기보다 실제 사용과 채택 데이터를 통해 부족한 부분을 확인하고 개선하는 방식을 택했다. - 특히 여러 사용자가 동시에 상호작용하는 커서 채팅 같은 멀티플레이어 기능은 스크린 리더 환경에 적합한 모델을 추가로 연구해야 한다. - 이번 출시는 전체 접근성 작업의 끝이 아니라, 이후 기능 확장을 위한 기반에 가깝다. 실제로 FigJam 파일을 만들 때는 요소에 명확한 텍스트와 이미지 대체 텍스트를 제공하고, 콘텐츠의 계층과 위치를 일관되게 구성하는 것이 좋다.

원문 읽기(새 탭에서 열림)

web-accessibilityfigjamReactkeyboard-navigation+2

figma·2022년 11월 16일·3분 읽기큐레이션 요약

피그마 접근성 팀과의 대화 | 피그마 블로그

Figma의 접근성 팀은 스크린 리더 지원을 개발 초기부터 다양한 사용자와 함께 검증해야 한다고 강조한다. 프로토타입 스크린 리더 베타를 통해 VoiceOver와 JAWS의 차이, 저시력 사용자의 시각·음성 병행 사용, 키보드 포커스의 중요성을 확인했다. Figma는 앞으로도 접근성 파트너와 협력해 지원 범위를 넓히고, 디자이너가 생성 HTML과 접근성 품질을 더 직접적으로 관리할 수 있는 도구를 제공할 계획이다. ## 오픈 베타를 통해 확인한 실제 사용자 요구 - 내부 테스트만으로는 실제 사용 환경과 보조공학 사용자의 요구를 충분히 파악하기 어렵다. - Mac VoiceOver에서는 잘 작동하던 기능도 JAWS 등 다른 스크린 리더에서는 추가 조정이 필요했다. - 스크린 리더 사용자는 시각 정보를 전혀 사용하지 않는 경우만 있는 것이 아니다. - 저시력 사용자는 화면의 시각 정보와 음성 정보를 함께 활용할 수 있다. - 다양한 상호작용 방식을 제공하면 더 넓은 사용자에게 도움이 된다. - 이에 따라 Figma는 주요 스크린 리더 기술을 개발 후반이 아니라 초기 단계부터 테스트하기로 했다. ## 시각 경험과 스크린 리더 경험의 연결 베타 테스트 결과, 스크린 리더 사용 경험은 시각적 UI와 분리된 별도 기능이 아니라 두 경험이 서로 보완되어야 한다는 점이 드러났다. - 접근성 트리에 요소의 위치 정보를 제공해, 시각 정보를 일부 활용하는 사용자가 스크린 리더 커서의 화면상 위치를 파악할 수 있게 했다. - 클릭 가능한 요소에 키보드 포커스가 있을 때도 “On hover” 상호작용을 실행하도록 조정했다. - 스크린 리더 커서가 이동하면 스크롤 영역도 함께 이동하도록 구현했다. - 프로토타입 도구 모음이 자동으로 숨겨질 때 키보드 포커스를 고려했다. - 화면을 탐색할 때 도구 모음이 방해되지 않아야 한다. - 동시에 현재 포커스된 컨트롤은 계속 화면에 보여야 한다. - 개발 과정에서 접근성 사용자를 단순히 “시각 사용자”와 “음성 사용자”로 나누는 기존 가정을 수정하게 됐다. ## 접근 가능한 프로토타입 진입 경로 프로토타입 자체가 스크린 리더로 접근 가능하더라도, Figma 디자인에서 해당 프로토타입으로 이동할 방법이 없으면 전체 경험은 접근 가능하지 않다. - 실제 출시 과정에서 프로토타이핑 모드로 바로 이동하는 단축키를 추가했다. - Mac: `Option + Command + Return` - PC: `Alt + Ctrl + Enter` - 스크린 리더 지원을 지속적으로 켤 수 있는 토글을 제공했다. - Figma Community를 통해 접근성 기능 사용법을 더 적극적으로 안내했다. - 기능 단위가 아니라 사용자가 처음부터 끝까지 수행하는 전체 흐름을 검증해야 한다는 교훈을 얻었다. ## 접근성 파트너와의 공동 테스트 Figma는 보조공학 사용자와 기업을 연결하는 Fable과 협력해 기능을 검증하고 있다. - Fable은 특정 사용자 흐름 테스트부터 심층 사용자 인터뷰까지 지원한다. - 사용자 피드백을 반영해 접근성 관련 컨트롤과 키보드 단축키를 더 쉽게 찾도록 개선하고 있다. - 접근성 탐색용 키보드 단축키를 키보드 단축키 패널에 포함하는 작업을 진행했다. - 키보드 단축키 패널 자체도 스크린 리더와 키보드로 접근 가능하도록 개선 중이다. - FigJam에서는 화면 구성의 정보 계층을 명확히 전달하기 위해 다음 정보를 스크린 리더에 제공한다. - 각 항목의 자식 수 - 형제 항목 수 - 캔버스 내 요소의 맥락을 파악하는 데 필요한 구조 정보 - 다양한 스크린 리더 소프트웨어와 숙련도 차이를 고려하면서 기능을 조정할 수 있었다. ## 앞으로의 접근성 방향 Figma 팀은 현재의 프로토타입 스크린 리더 지원이 완성된 상태가 아니라고 설명한다. - 콘텐츠가 기본적으로 스크린 리더 사용자에게 항상 제공되도록 하는 것을 우선순위로 삼고 있다. - 디자이너가 Figma가 생성하는 HTML을 더 세밀하게 제어할 수 있도록 할 계획이다. - 스크린 리더에 익숙하지 않은 디자이너도 자신의 디자인 접근성을 평가할 수 있는 도구를 개발하려 한다. - 접근성을 출시 직전의 점검 항목이 아니라 제품 설계와 개발 전반에 포함되는 기준으로 정착시키려 한다. 접근성 기능을 만들 때는 특정 스크린 리더 하나만 기준으로 삼지 말고, 실제 보조공학 사용자와 함께 초기 단계부터 테스트하는 것이 중요하다. 또한 개별 기능의 접근성뿐 아니라 사용자가 해당 기능에 도달하고, 탐색하고, 조작하는 전체 경로를 검증해야 한다.

원문 읽기(새 탭에서 열림)

web-accessibilityHTMLkeyboard-navigationscreen-readers+1