google·2025년 10월 28일원문

StreetReaderAI: 문맥 인식 (새 탭에서 열림)

StreetReaderAI는 구글 리서치에서 개발한 시각장애인 및 저시력자를 위한 혁신적인 스트리트 뷰 프로토타입으로, 멀티모달 AI인 Gemini를 활용해 시각적 정보를 실시간 음성 정보로 변환합니다. 기존 지도 서비스가 제공하지 못했던 스트리트 뷰 이미지의 맥락과 지리적 특성을 실시간 대화형 인터페이스로 설명함으로써, 시각장애인이 가상 세계를 자유롭게 탐색하고 실제 경로를 미리 파악할 수 있도록 돕는 것이 이 기술의 핵심입니다. **사용자 중심의 직관적 내비게이션** * 키보드 화살표 키나 음성 명령을 사용하여 게임을 하듯 가상 공간 내 시점 전환 및 이동이 가능합니다. * 사용자가 시점을 회전할 때마다 현재 방위(예: "북동쪽을 보고 있습니다")와 정면에 랜드마크나 장소가 있는지를 음성으로 즉각 피드백합니다. * "가상 걸음(Virtual steps)" 기능을 통해 앞뒤로 이동하며 이동 거리와 도로 정보, 주변 상점 및 시설물에 대한 정보를 실시간으로 수신할 수 있습니다. **AI 디스크라이버(AI Describer)를 통한 상황별 맥락 인식** * 단순한 이미지 분석을 넘어 사용자의 위도·경도, 도로 데이터, 현재 시야의 스트리트 뷰 이미지를 결합해 맞춤형 설명을 생성합니다. * 보행 안전과 내비게이션 정보에 집중하는 '기본 모드'와 지역의 역사적·건축적 배경을 상세히 설명하는 '투어 가이드 모드'를 제공합니다. * 사용자가 현재 장면에서 궁금해할 만한 후속 질문(예: "저 건물의 입구는 어디인가요?")을 AI가 스스로 예측하여 제안함으로써 탐색의 효율성을 높였습니다. **AI 채팅과 강력한 세션 메모리 기능** * Gemini Multimodal Live API를 활용하여 사용자와 실시간 대화가 가능하며, 사용자의 질문에 맞춰 시각적 정보를 해석합니다. * 약 100만 토큰 이상의 긴 컨텍스트 윈도우를 활용해 사용자가 세션 동안 탐색한 모든 경로와 이미지를 기억합니다. * 이를 통해 "방금 지나온 버스 정류장에 벤치가 있었니?" 또는 "아까 본 편의점에서 여기까지 얼마나 떨어져 있어?"와 같은 과거의 맥락이 포함된 복합적인 질문에 정확히 답변할 수 있습니다. **사용자 평가 및 실무적 시사점** 11명의 시각장애인을 대상으로 한 연구 결과, 사용자들은 StreetReaderAI를 통해 목적지의 지형지물을 미리 확인하고 보행 경로를 계획하는 데 큰 도움을 얻었습니다. 이 기술은 수조 개의 스트리트 뷰 이미지를 텍스트 기반의 데이터로 변환할 필요 없이, 필요할 때마다 실시간으로 AI가 해석해 준다는 점에서 확장성이 매우 높습니다. 향후 이와 같은 멀티모달 AI 기술이 지도 앱에 통합된다면 시각장애인의 이동권과 정보 접근성을 획기적으로 개선할 수 있을 것입니다.

assistive-technologyAI접근성gemini+5

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

Figma에서 접근성을 개선하는

Figma는 키보드만으로 캔버스와 댓글을 조작하고, 스크린 리더로 파일 내용을 더 정확히 이해할 수 있도록 15가지 이상의 접근성 기능을 출시했다. 제품별 키보드 단축키, 더 논리적인 포커스 이동, 풍부한 객체 설명과 서식 정보, 향상된 색상 대비가 포함된다. 이를 통해 장애가 있는 사용자뿐 아니라 장시간 작업하거나 다양한 환경에서 Figma를 사용하는 모든 사용자의 탐색성과 작업 흐름을 개선하는 것이 목표다. ## 캔버스 조작을 위한 키보드 기능 확대 - 키보드만으로 캔버스 객체를 이동·조정·정렬할 수 있는 기능이 제품 전반으로 확대됐다. - **Figma Slides** - 발표자 노트 크기 조정 - AI를 활용한 글쓰기 톤 변경 - **FigJam** - 표의 행과 열 추가·삭제·순서 변경 - 스탬프, 투표, 와시 테이프 추가 및 조정 - AI 요약, 임베드 링크·동영상 같은 캔버스 객체 탐색 - 마커 선과 형광펜 스트로크 선택 및 조정 - **Figma Design** - 선 추가·선택·조정 - 룰러 가이드 추가·삭제·편집 - 타원에서 호(arc) 생성 및 편집 - **공통 기능** - 편집 모드와 보기 전용 모드에서 링크 열기 - 키보드로 링크 사이를 이동 ## 댓글과 Dev Mode 주석 탐색 - 댓글을 추가하고, 위치를 옮기고, 댓글 간 이동을 키보드 단축키로 처리할 수 있다. - Dev Mode 주석도 키보드로 추가·이동·탐색할 수 있다. - 피드백을 확인하거나 답변할 때 포커스가 흐트러지지 않도록 설계되어 협업과 핸드오프 과정이 개선된다. - 댓글 관련 기능은 베타 제품에서는 제공되지 않을 수 있다. ## 사용자 설정을 통한 조작 방식 개인화 - 입력 중 Figma 전용 단축키가 동작하지 않도록 설정할 수 있다. - 다른 사용자가 스포트라이트를 사용할 때 자동으로 따라가는 기능을 켜거나 끌 수 있다. - 사용자는 작업 방식이나 보조기술 사용 환경에 맞춰 키보드 동작을 조정할 수 있다. ## 스크린 리더 지원 강화 - 버튼, 메뉴, 패널 등 인터랙티브 요소를 Tab 키로 이동할 때 더 논리적인 순서를 따른다. - 메뉴 열기, 버튼 실행, 툴바 옵션 선택 등 특정 동작으로 바로 이동할 수 있다. - 객체를 읽을 때 유형, 이름, 상태 등 더 자세한 정보가 제공된다. - 새 댓글이나 파일 변경 사항 같은 중요한 업데이트가 더 일관되게 안내된다. - 굵게, 기울임, 목록, 링크 등 서식 있는 텍스트 구조를 스크린 리더가 보존해 읽는다. - Buzz와 Slides의 캔버스 객체도 스크린 리더가 인식하고 안내한다. - 이러한 개선은 캔버스의 객체 순서를 파악하고 파일 변경 사항을 놓치지 않도록 돕는다. ## 향상된 색상 대비 - 간단한 토글로 라이트 모드와 다크 모드 모두에서 인터페이스의 색상 대비를 높일 수 있다. - 접근성 설정, Actions 메뉴, General 설정에서 기능을 활성화할 수 있다. - 텍스트와 아이콘의 가독성이 높아지고, 버튼과 외곽선이 더 뚜렷하게 표시된다. - 인터페이스 구조를 파악하고 필요한 요소를 빠르게 찾기 쉬워진다. - 햇빛이나 강한 조명 아래에서도 화면을 보기 쉬우며, 장시간 화면을 사용하는 경우 눈의 부담을 줄일 수 있다. ## 실용적인 활용 키보드 중심으로 작업하는 사용자는 Figma의 전체 키보드 컨트롤 목록을 확인해 자주 쓰는 캔버스·댓글 단축키를 익히는 것이 좋다. 스크린 리더 사용자는 객체 설명과 서식 있는 텍스트 지원을 활용하고, 일반 사용자도 색상 대비 설정을 활성화하면 장시간 작업이나 밝은 환경에서 더 편하게 Figma를 사용할 수 있다.

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

assistive-technologyFigmafigjam접근성+4

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을 더 세밀하게 제어할 수 있도록 할 계획이다. - 스크린 리더에 익숙하지 않은 디자이너도 자신의 디자인 접근성을 평가할 수 있는 도구를 개발하려 한다. - 접근성을 출시 직전의 점검 항목이 아니라 제품 설계와 개발 전반에 포함되는 기준으로 정착시키려 한다. 접근성 기능을 만들 때는 특정 스크린 리더 하나만 기준으로 삼지 말고, 실제 보조공학 사용자와 함께 초기 단계부터 테스트하는 것이 중요하다. 또한 개별 기능의 접근성뿐 아니라 사용자가 해당 기능에 도달하고, 탐색하고, 조작하는 전체 경로를 검증해야 한다.

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

assistive-technologyHTMLkeyboard-navigationscreen-readers+1

figma·2018년 6월 19일·3분 읽기큐레이션 요약

한 디자이너가 더 윤리

Cat Noone은 접근성을 제품 개발의 마지막 점검이 아니라 초기 설계 원칙으로 삼아야 한다고 주장한다. 그녀는 의료 정보 공유 앱 Iris Health, 색각 이상 접근성 도구 Stark, 자폐 아동용 의사소통 앱 Lyra를 통해 소외되기 쉬운 사용자도 제품의 기본 사용자로 고려해야 한다는 점을 보여준다. 접근성을 높이는 일은 디자인을 제한하는 것이 아니라 더 많은 사람에게 제품을 열어 주는 방법이다. ## 접근성을 처음부터 고려해야 하는 이유 - 장애가 있는 사용자 중 상당수가 온라인 서비스를 이용하므로, 접근성을 무시하면 잠재 사용자층의 약 10%를 놓칠 수 있다. - 접근성을 “UI를 나쁘게 만드는 제약”으로 보는 인식을 비판한다. - 제품 기획 단계부터 신체적·인지적·감각적 특성이 다른 사용자들을 조사하고, 각 집단에 맞게 UI와 기능을 조정해야 한다. - “전형적인 사용자”라는 가정 자체가 기술 업계의 사각지대를 만들 수 있다. ## Iris Health: 위급 상황에서 의료 정보를 전달하는 서비스 - 해외 체류 중 사고가 발생하면 가족이나 의료진이 사용자의 알레르기, 복용 약, 혈액형, 당뇨 여부 등을 알기 어렵다는 문제에서 출발했다. - 사용자가 병원에 있는 것으로 감지되면 안부를 확인하고, 10분 안에 응답이 없을 경우 등록된 비상 연락처에 문자 메시지를 보낸다. - iPhone 잠금 화면에 의료 카드가 표시되어 의료진이 이름, 약물, 알레르기, 장기 기증 여부 등의 정보를 빠르게 확인할 수 있다. - 만성질환자뿐 아니라 해외 거주자, 응급 상황에서 의사 표현이 어려운 사람에게도 유용하도록 설계됐다. - **교훈:** 사용자의 상황을 여러 각도에서 상상하고, 다양한 사용자 집단이 실제로 서비스를 어떻게 사용할지 충분히 검토해야 한다. ## Stark: 색각 이상과 대비를 확인하는 디자인 도구 - 의료 앱을 만들면서 접근성을 지원하는 디자인 도구가 부족하다는 문제를 발견해 개발했다. - Sketch에서 레이어를 선택해 다양한 색각 이상 유형을 시뮬레이션할 수 있다. - 텍스트와 배경색의 대비 비율을 확인해 색상 조합이 읽기 어려운지 판단할 수 있다. - Twitter, ESPN, Palantir, Dropbox, Microsoft 등의 팀에서도 사용됐다. - 접근성 검사를 별도 업무로 미루지 말고 디자인 워크플로에 기본 기능처럼 포함해야 한다. - Stark 외에도 Contrast, W3C 접근성 체크리스트 등을 활용해 표준 준수 여부와 개선점을 점검할 수 있다. - 시각과 촉각을 함께 고려한 Braille Neue 같은 서체도 접근성을 확장하는 사례로 소개된다. ## Lyra: 자폐 아동을 위한 기호-음성 의사소통 앱 - 대학 시절 다양한 특수 필요를 가진 아동들과 일한 경험을 바탕으로 시작됐다. - 비언어적 자폐 아동이 기호를 선택해 음성으로 의사를 표현할 수 있도록 돕는다. - 1985년부터 사용된 라미네이트 카드와 벨크로 방식의 의사소통 도구를 디지털 환경에 맞게 현대화하려는 프로젝트다. - 기존 방식은 아동이 디지털 세계에 참여하는 데 한계가 있으므로, 더 편리하고 자연스러운 의사소통 수단을 제공하려 한다. - 개발팀은 당시 베타 버전 출시를 준비하고 있었다. - **교훈:** 접근성 디자인을 제대로 만들려면 관련 사용자와 문제 영역을 스스로 학습해야 하며, Microsoft의 Inclusive Design 가이드 같은 자료부터 참고할 수 있다. 제품을 만들 때 접근성을 출시 직전의 검수 항목으로 두기보다, 사용자 조사·정보 구조·시각 디자인·개발 도구에 기본값으로 포함하는 것이 좋다. 특히 실제 장애 사용자와 함께 테스트하고, 색상 대비·키보드 사용·의사소통 방식 등 구체적인 사용 조건을 반복적으로 검증해야 한다.

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

assistive-technology사용자 인터페이스접근성sketch+3