Good, Better, Best: 복잡한 접근 가능한 패턴의 세계 풀기

마크 베니오프(Marc Benioff)는 기술 산업에서 유일하게 변하지 않는 것은 변화라고 기억에 남습니다. 15년 이상 기술 분야에서 일해왔기 때문에 이를 확인할 수 있습니다. 동료 기술 공룡은 초기에 웹이 작동하는 방식이 우리 중 많은 사람들이 상상할 수 있었던 것과 크게 다르다는 것을 증명할 수 있습니다.

기술 산업의 이러한 끊임없는 변화는 오늘날 우리가 볼 수 있는 혁신과 발전을 가져왔지만 선택의 개념도 도입했습니다. 표면적으로는 선택이 본질적으로 긍정적인 것처럼 보일 수 있지만 항상 무지개와 장미와 같은 것은 아닙니다. 기술 변화의 유입은 코딩 언어의 분열과 프로그래밍의 끝없는 풍미 "핫"도 가져옵니다. 때때로 이러한 선택의 폭은 과잉 선택으로 바뀌는데, 이는 사람들이 선택지가 너무 많아 결정을 내리는 데 어려움을 겪는 잘 연구된 인지 장애입니다.

이 기사에서 우리는 접근 가능한 패턴의 복잡한 세계를 한 번에 한 단계씩 풀려고 시도할 것입니다. 현재 액세스 가능한 패턴과 라이브러리를 검토하여 작업을 시작한 다음 일반적인 패턴 요구 사항과 잠재적 제한 사항을 고려하고 마지막으로 액세스 가능성에 대한 패턴을 더 잘 평가하는 방법을 배우기 위해 일련의 비판적 사고 연습을 살펴보겠습니다.

우리가 짜는 얽힌 웹

Overchoice는 단순한 체크박스에서 복잡한 동적 모달 및 그 사이의 모든 것에 이르기까지 디지털 창작물을 구축하는 데 사용하는 패턴과 라이브러리를 포함하여 기술의 모든 측면에 스며들었습니다. 그러나 선택 사항이 너무 많을 때 어떤 패턴이나 라이브러리가 올바른지 어떻게 알 수 있습니까? 사용자가 매일 접하는 기존 패턴/라이브러리를 사용하는 것이 더 나은가요? 아니면 더 즐거운 사용자 경험을 위해 완전히 새로운 패턴을 만드는 것이 더 낫습니까?

선택의 여지가 무수히 많기 때문에 우리는 선택의 과잉으로 인해 빠르게 마비될 수 있습니다. 그러나 한발 물러서서 왜 우리가 디지털 제품을 처음부터 구축하는지(즉, 최종 사용자) 고려한다면, 가장 많은 사람들에게 가장 큰 가치를 더할 수 있는 패턴이나 라이브러리를 선택하는 것이 이치에 맞지 않습니다. ?

패턴이나 라이브러리를 선택하는 것이 이미 충분히 어려운 과정이라고 생각했다면, 이것이 걱정되기 시작하는 지점일 수 있습니다. 그러나 걱정할 필요가 없습니다. 접근 가능한 패턴/라이브러리를 선택하는 것은 로켓 과학이 아닙니다. 기술의 다른 모든 것과 마찬가지로 이 여정은 약간의 지식, 엄청난 시행착오, 모든 사용자, 상황 또는 프레임워크에 맞는 하나의 완벽한 패턴/라이브러리가 없다는 이해로 시작됩니다.

내가 이것을 어떻게 알 수 있습니까? 저는 지난 5년 동안 A11y 스타일 가이드, Deque의 ARIA 패턴 라이브러리를 작업하고 인기 있는 SVG 패턴을 평가하면서 다양한 유형의 액세스 가능한 패턴을 연구, 구축 및 테스트하는 데 보냈습니다. 그러나 상상할 수 있는 모든 프레임워크/플랫폼에서 많은 클라이언트 패턴과 라이브러리도 검토했습니다. 이 시점에서 나는 충분히 오래 볼 때 발전하기 시작하는 패턴 접근성에 대한 타고난 계층이 있다고 주저 없이 말할 수 있습니다. 때로는 어떤 대가를 치르더라도 피해야 할 패턴이 있지만 항상 그렇게 명확하지는 않습니다. 접근성과 관련하여 저는 대부분의 패턴이 좋음, 더 좋음, 가장 좋음의 기울기에 속한다고 주장합니다. 어려운 부분은 어떤 패턴이 어떤 범주에 속하는지 아는 것입니다.

패턴에 대해 비판적으로 생각하기

그렇다면 접근성과 관련하여 어떤 패턴이 좋은지, 더 나은지, 가장 좋은지 어떻게 알 수 있습니까? 때에 따라 다르지. 디지털 접근성 커뮤니티에서 자주 사용되는 이 문구는 도피가 아니라 "최상의 답변을 제공할 수 있도록 더 많은 컨텍스트가 필요합니다."의 약어입니다. 그러나 컨텍스트가 항상 명확한 것은 아니므로 패턴의 접근성을 구축하고 평가할 때 다음과 같은 몇 가지 기본적인 질문을 던집니다.

• 우리가 사용할 수 있는 접근 가능한 패턴이 이미 확립되어 있습니까?
• 어떤 브라우저와 보조 기술(AT) 장치를 지원합니까?
• 고려해야 할 프레임워크 제한 또는 기타 통합/요인이 있습니까?

물론 귀하의 구체적인 질문은 나와 다를 수 있지만 요점은 패턴을 평가할 때 비판적 사고 기술을 사용하기 시작해야 한다는 것입니다. 최종 결정으로 넘어가기 전에 먼저 각 패턴을 관찰하고 분석한 다음 접근성에 대한 순위를 지정하여 이를 수행할 수 있습니다. 그러나 우리가 그것에 도달하기 전에 먼저 초기 질문에 대해 조금 더 파고들자.

이미 확립된 접근 가능한 패턴이 있습니까?

각각의 새로운 프레임워크에서 완전히 새로운 패턴 세트를 얻는 것처럼 보이는 이유는 무엇입니까? 새로운 패턴 선택으로 휠을 끊임없이 재창조하면 특히 일반적으로 그렇게 할 필요가 없기 때문에 개발자를 혼란스럽게 하고 좌절시킬 수 있습니다.

날 믿지 않아? 음, 이렇게 생각해 보세요. 원자 설계 시스템에 가입하면 코드의 여러 작은 "원자"가 함께 모여 더 큰 디지털 제품을 만든다는 것을 이해합니다. 그러나 과학 세계에서 원자는 생명의 가장 작은 구성 요소가 아닙니다. 각 원자는 양성자, 중성자 및 전자와 같은 많은 아원자 입자로 구성됩니다.

동일한 논리를 패턴에 적용할 수 있습니다. 존재하는 다양한 프레임워크에서 사용할 수 있는 모든 패턴을 더 자세히 살펴보면 사용되는 실제 코딩 언어에 관계없이 핵심 아원자 구조는 본질적으로 동일합니다. 이것이 내가 기술 및 디자인 요구 사항을 기반으로 구축할 수 있는 액세스 가능한 패턴이 있는 간소화된 코딩 라이브러리에 감사하는 이유입니다.

참고 : Smashing Magazine이 최근에 출판한 접근 가능한 패턴 목록(기사 끝 부분에 더 자세한 패턴 및 라이브러리 목록 포함) 외에 포함된 구성 요소, 접근 가능한 구성 요소 및 Gov.UK 디자인 시스템이 포함됩니다. .

지원하는 브라우저 및 보조 기술(AT) 장치는 무엇입니까?

작동할 수 있는 몇 가지 기본 패턴을 조사한 후 브라우저 및 보조 기술(AT) 장치 지원 문제로 넘어갈 수 있습니다. 브라우저 지원 자체가 장난이 아닙니다. AT 장치와 ARIA 사양을 믹스에 추가하면 모든 것이 복잡해지기 시작합니다…

하지만 나쁜 소식만 있는 것은 아닙니다. HTML5 접근성 및 접근성 지원과 같은 멋진 리소스가 있어 현재 브라우저 + AT 장치 지원에 대해 더 잘 이해할 수 있습니다. 이 웹사이트는 사용 가능한 다양한 HTML 및 ARIA 패턴 하위 요소를 간략하게 설명하고 오픈 소스 커뮤니티 테스트를 포함하며 데스크톱 및 모바일 브라우저/AT 장치 모두에 대한 몇 가지 패턴 예제를 제공합니다.

프레임워크 제한 사항이나 고려해야 할 기타 통합/요소가 있습니까?

액세스 가능한 몇 가지 기본 패턴을 선택하고 브라우저/AT 장치 지원을 고려한 후에는 패턴 및 해당 환경에 대한 보다 세분화된 컨텍스트 질문으로 이동할 수 있습니다. 예를 들어 콘텐츠 관리 시스템(CMS)에서 패턴을 사용하거나 레거시 코드 고려 사항이 있는 경우 특정 패턴 제한이 있습니다. 이 경우 소수의 패턴 선택이 빠르게 하나 또는 둘로 줄어들 수 있습니다. 반면에 일부 프레임워크는 더 관대하고 모든 패턴을 받아들이는 데 개방적이므로 프레임워크 제한에 대해 덜 걱정하고 우리가 할 수 있는 가장 접근하기 쉬운 패턴 선택에 더 집중할 수 있습니다.

지금까지 논의한 모든 것 외에도 성능, 보안, 검색 엔진 최적화, 언어 번역, 타사 통합 등과 같이 패턴을 선택할 때 고려해야 할 추가 고려 사항이 많이 있습니다. 이러한 요소는 액세스 가능한 패턴 선택에 의심의 여지가 없지만 콘텐츠를 만드는 사람들에 대해서도 생각해야 합니다. 선택하는 액세스 가능한 패턴은 편집자 생성 및/또는 사용자 생성 콘텐츠와 관련된 잠재적인 제한 사항을 처리할 수 있을 만큼 충분히 강력한 방식으로 구축되어야 합니다.

접근성 패턴 평가

코드는 종종 말보다 더 큰 소리로 말하지만, 그 모든 것을 다루기 전에 다음 패턴 예제가 각 상황에 사용할 수 있는 유일한 패턴이 아니며 그룹에서 "최고"로 간주되는 패턴이 그룹에서 가장 좋은 옵션으로 간주되지 않는다는 점에 간단히 유의하십시오. 접근 가능한 패턴의 전 세계.

아래의 패턴 데모에서는 각 패턴 그룹을 자체적으로 비교하는 가상의 상황을 상상해야 합니다. 이것이 현실적인 상황은 아니지만 이러한 비판적 사고 연습을 실행하고 접근성에 대한 패턴을 평가하면 현실 세계에서 패턴 선택에 직면했을 때 보다 준비하는 데 도움이 될 것입니다.

접근 가능한 버튼 패턴

접근성에 대해 검토할 첫 번째 패턴 그룹은 거의 모든 웹사이트나 앱에 어디에나 있는 버튼입니다. 첫 번째 버튼 패턴은 버튼을 모방하기 위해 ARIA 버튼 역할을 사용하는 반면, 두 번째 및 세 번째 버튼 패턴은 HTML <button> 요소를 사용합니다. 세 번째 패턴은 또한 시각적으로 사물을 숨기기 위해 aria-describedby 및 CSS를 추가합니다.

좋은: role="button"

 <a role="button" href="[link]">Sign up</a>

더 나은: <button>

 <button type="button">Sign up</button>

최고: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

첫 번째 패턴은 언뜻 보기에는 단순해 보이지만 몇 가지 접근성 질문을 불러일으킵니다. 예를 들어 첫 번째 버튼 패턴에서 HTML <button> 요소 대신 "좋은" 패턴에 ARIA role="button" 이 사용된 것을 볼 수 있습니다. 접근성 측면에서 생각해보면 HTML <button> 요소가 HTML4에 도입되었다는 것을 알고 있기 때문에 모든 주요 브라우저의 최신 버전에서 완전히 지원되며 대부분의 AT 장치에서 잘 작동할 것이라고 합리적으로 추측할 수 있습니다. 그러나 ARIA 역할=“버튼”에 대한 접근성 지원을 더 깊이 파고들면 보조 기술 관점에서 약간의 이점이 있는 반면 HTML <button> 요소에는 브라우저 + AT 적용 범위의 일부 영역이 누락되었습니다. 특히 다음을 고려할 때 음성 제어 지원.

그렇다면 왜 ARIA 패턴이 "더 나은" 범주에 있지 않습니까? ARIA를 사용하면 더 쉽게 액세스할 수 있습니까? 아니요. 사실, 이와 같은 경우 접근성 전문가는 종종 ARIA의 첫 번째 규칙을 암송합니다. ARIA를 사용하지 마십시오. 이것은 가능할 때마다 HTML 요소를 사용하는 것을 말하는 것입니다. ARIA는 실제로 강력하지만 악의적인 사람이 사용하면 득보다 실이 더 많을 수 있습니다. 실제로 WebAIM Million 보고서에 따르면 "ARIA가 있는 페이지는 그렇지 않은 페이지보다 평균 60% 더 많은 오류가 발생했습니다." 따라서 ARIA를 사용할 때 무엇을 하고 있는지 알아야 합니다.

이 상황에서 ARIA를 사용하는 것에 대한 또 다른 문제는 우리가 필요로 하는 버튼 기능이 role="button" 패턴에 대해 구축되어야 하는 반면 해당 기능은 이미 <button> 요소에 미리 구워져 있다는 것입니다. <button> 요소도 브라우저를 100% 지원하고 구현하기 쉬운 패턴이라는 점을 고려하면 처음 두 패턴을 평가할 때 계층 구조에서 약간 앞서 있습니다. 바라건대, 이 비교는 ARIA를 추가하면 패턴에 더 쉽게 접근할 수 있다는 통념을 깨는 데 도움이 됩니다. 종종 그 반대가 사실입니다.

세 번째 버튼 패턴은 CSS로 시각적으로 숨겨진 ID 요소에 연결된 aria-describedby 와 결합된 HTML <button> 요소를 보여줍니다. 이 패턴은 약간 더 복잡하지만 버튼과 목적 간의 관계를 생성하여 컨텍스트 측면에서 많은 것을 추가합니다. 의심스러울 때 상황에 더 많은 컨텍스트를 추가할 수 있을수록 더 좋으므로 올바르게 코딩된 경우 이러한 특정 버튼 패턴만 비교할 때 가장 좋은 패턴이라고 가정할 수 있습니다.

접근 가능한 컨텍스트 링크 패턴

우리가 검토할 두 번째 패턴 그룹은 컨텍스트 링크입니다. 이러한 패턴은 AT 사용자에게 화면에 표시되는 것보다 더 많은 정보를 제공하는 데 도움이 됩니다. 첫 번째 링크 패턴은 CSS를 사용하여 추가 컨텍스트 정보를 시각적으로 숨깁니다. 두 번째 및 세 번째 링크 패턴은 혼합에 ARIA 속성(각각 aria-labelledby 및 aria-label )을 추가합니다.

Carie Fisher의 펜 [접근 가능한 링크 패턴](https://codepen.io/smashingmag/pen/VwmRJYv)을 참조하십시오.

좋음: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

더 나은: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

베스트: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

세 가지 컨텍스트 링크 패턴은 모두 같아 보이지만 코드를 검사하거나 AT 장치로 테스트할 때 몇 가지 분명한 차이점이 있습니다. 첫 번째 패턴은 CSS 기술을 사용하여 시각 사용자에게는 시각적으로 콘텐츠를 숨기지만 여전히 보이지 않는 AT 사용자에게는 숨겨진 콘텐츠를 렌더링합니다. 그리고 이 기술 은 대부분의 경우에 작동해야 하지만 링크와 추가 정보 사이에는 실제 관계가 형성되지 않으므로 연결은 기껏해야 잠정적입니다. 따라서 첫 번째 링크 패턴은 괜찮은 선택이지만 세 가지 중 가장 강력한 링크 패턴은 아닙니다.

다음 두 링크 패턴은 평가하기가 조금 더 까다롭습니다. W3C의 ARIA 사양에 따르면 “ aria-label aria-labelledby 의 목적과 같습니다. 사용자에게 개체의 인식할 수 있는 이름을 제공합니다." 따라서 이론상 두 속성은 기본 기능이 동일해야 합니다.

그러나 사양은 또한 사용자 에이전트가 사용자에게 전달할 액세스 가능한 이름을 결정할 때 aria-label 보다 aria-labelledby 를 우선시한다는 점을 지적합니다. 연구에 따르면 자동 번역 및 aria-label 속성과 관련된 문제도 있습니다. 그러니까 aria-labelledby 를 사용해야 한다는 뜻이죠?

글쎄, 그렇게 빠르지 않습니다. 동일한 ARIA 사양은 계속해서 "인터페이스가 화면에 보이는 레이블을 가질 수 없는 경우(또는 보이는 레이블이 원하는 사용자 경험이 아닌 경우), 작성자 는 aria-label을 사용해야 하고 aria-label 을 사용 해서는 안 됩니다. aria-labelledby 사용하십시오.” 혼란에 대해 이야기하십시오. 그렇다면 어떤 패턴을 선택해야 할까요?

대규모 번역이 필요한 경우 시각적 측면을 변경하고 전체 컨텍스트가 표시된 링크를 작성하기로 결정하거나(예: " 이 멋진 것에 대해 자세히 알아보기 ") aria-labelledby 를 사용하기로 결정할 수 있습니다. 그러나 대규모 번역 요구 사항이 없거나 합리적이고 접근 가능한 방식으로 이러한 요구 사항을 해결할 수 있고 시각적 개체를 변경하고 싶지 않다고 가정해 보겠습니다. 그러면 어떻게 될까요?

현재 ARIA 1.1 권장 사항(ARIA 1.2에서 aria-label의 번역 약속 포함)과 aria-label 이 aria-labelledby 에 비해 개발자가 구현하기가 조금 더 쉽다는 사실을 기반으로 aria- aria-label 에 가중치를 주기로 결정할 수 있습니다. 패턴 평가에서 aria-labelledby . 이것은 접근 가능한 패턴 선택에서 컨텍스트가 매우 중요한 경우를 보여주는 분명한 예입니다.

액세스 가능한 <svg> 패턴

마지막으로 접근성을 위한 SVG 이미지 패턴 그룹을 조사해 보겠습니다. SVG는 코드의 시각적 표현이지만 그럼에도 불구하고 코드입니다. 이것은 role="img" 가 패턴에 추가되지 않는 한 AT 장치가 장식이 아닌 SVG 이미지를 건너뛸 수 있음을 의미합니다.

다음 SVG 패턴이 본질적으로 정보 제공이라고 가정하면 각각에 role="img" 가 포함됩니다. 첫 번째 SVG 패턴은 CSS와 함께 <title> 및 <text> 를 사용하여 시각 사용자로부터 콘텐츠를 시각적으로 숨깁니다. 다음 두 SVG 패턴에는 <title> 및 <desc> 요소가 포함되지만 마지막 패턴에 aria-labelledby 속성이 추가됩니다.

좋음: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

더 나은: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

최고: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

먼저 <title> 과 <text> 를 사용한 첫 번째 패턴과 시각적으로 숨겨진 CSS를 살펴보자. 패턴에서 이전의 눈에 띄게 숨겨진 텍스트와 달리 <title> 및 <text> 요소는 동일한 SVG 요소 우산 아래에 그룹화되어 있기 때문에 고유한 관계가 있습니다. 그러나 이 관계는 그리 강하지 않습니다. 사실, SVG 패턴에 대한 나의 연구를 되돌아보면, 8개의 브라우저/AT 조합 중 3개만이 완전한 메시지를 들었다는 것을 알 수 있습니다. (참고: 돼지 패턴 #1은 전구 패턴 #7과 동일합니다.)

작업 중인 W3C SVG 사양에서 <text> 요소를 "텍스트로 구성된 그래픽 요소… 그릴 문자는 문자 데이터로 표현됩니다. 결과적으로 SVG 콘텐츠의 텍스트 데이터는 시각 장애인이 쉽게 액세스할 수 있습니다.” 이 첫 번째 패턴은 괜찮지만 더 잘할 수 있습니다.

두 번째 패턴은 <text> 요소를 제거하고 <desc> 요소로 대체합니다. W3C SVG 사양은 다음과 같습니다.

" <title> 자식 요소는 요소에 대한 짧은 텍스트 대안을 나타내며, <desc> 요소는 설명과 같은 요소에 대한 보다 자세한 텍스트 정보를 나타냅니다."

SVG의 <title> 및 <desc> 요소는 전통적으로 <img> 요소에 있는 이미지 대체 텍스트 및 긴 설명 옵션과 유사하게 사용할 수 있음을 의미합니다. 두 번째 SVG에 <desc> 요소를 추가한 후 완전한 메시지를 듣는 8개 조합 중 3개와 유사한 브라우저/AT 지원을 볼 수 있습니다. (참고: 돼지 패턴 #2는 전구 패턴 #10과 동일합니다.) 이 테스트 결과는 첫 번째 패턴을 반영하는 것처럼 보이지만 이 패턴이 "더 나은" 범주에 들어가는 이유는 코드 구현이 약간 더 쉽기 때문입니다. 현명하고 JAWS, VoiceOver 데스크탑 및 VoiceOver 모바일에서 작동하므로 더 많은 AT 사용자에게 영향을 미치는 반면, 첫 번째 패턴은 덜 인기 있는 브라우저/AT 조합을 지원했습니다.

세 번째 패턴은 다시 <title> 및 <desc> 요소를 사용하지만 이제 aria-labelledby 와 ID가 믹스에 추가되었습니다. 동일한 SVG 테스트에 따르면 이 추가 코드를 추가하면 브라우저/AT 조합 8개 중 7개를 완벽하게 지원할 수 있습니다. (참고: 돼지 패턴 #3은 전구 패턴 #11과 동일합니다.) 세 가지 SVG 패턴 중 이 세 번째 패턴은 대부분의 AT 장치를 지원하기 때문에 "최고"입니다. 그러나 이 패턴에는 일부 브라우저/AT 조합을 사용할 때 단점이 있습니다. 이 패턴에 대해 중복된 이미지 제목/설명 내용을 듣게 됩니다. 사용자에게 잠재적으로 성가시게 될 수 있지만, 나는 일반적으로 중복된 콘텐츠를 전혀 듣지 않는 것보다 듣는 것이 더 낫다고 주장하고 싶습니다.

마무리 생각

우리 모두는 확실히 기술의 선택을 중요하게 생각하지만, 너무 많은 옵션이 우리를 마비시키고 다음에 무엇을 해야 할지 혼란스럽게 만드는 시점에 이르렀는지 궁금합니다. 접근 가능한 패턴 선택과 관련하여 패턴/라이브러리 옵션, 브라우저/AT 장치 지원, 프레임워크 제한 등에 대한 직접적인 질문을 할 수 있습니다.

올바른 데이터가 있으면 이러한 질문에 쉽게 답할 수 있습니다. 그러나 패턴을 넘어 실제로 사용하는 사람들을 고려하면 조금 더 복잡해집니다. 그제서야 우리의 선택이 사용자의 성공 능력에 미치는 영향을 깨닫게 됩니다. George Dei 교수는 다음과 같이 웅변적으로 말합니다.

"포용은 사람들을 이미 존재하는 곳으로 데려오는 것이 아니라 새로운 공간, 모두를 위한 더 나은 공간을 만드는 것입니다."

패턴에 대해 비판적으로 생각하고 가장 접근하기 쉬운 패턴을 선택하는 데 더 많은 시간을 할애함으로써 우리는 의심할 여지 없이 더 많은 사용자에게 도달할 수 있는 더 포괄적인 공간을 만들 것입니다.

관련 리소스

도구

• 접근성 지원, Michael Fairchild, 11ysupport.io
• HTML5 접근성, 스티브 포크너

패턴 라이브러리

• 접근성 프로젝트
• 접근성 스타일 가이드
• 접근 가능한 구성 요소, Scott O'Hara
• 액세스 가능한 drag-and-drop 목록 재정렬 플러그인, Harris Schneiderman
• Deque의 ARIA 패턴 라이브러리
• Deque의 접근 가능한 React 라이브러리
• GOV.UK 디자인 시스템
• 포함 구성 요소, Heydon Pickering
• 미국 웹 디자인 시스템(USWDS)
• 웹 접근성 튜토리얼