스매싱 팟캐스트 에피소드 4 With Heydon Pickering: 포함 구성 요소란?

오늘 저는 Heydon Pickering과 그의 새 책 Inclusive Components 에 대해 이야기합니다. Heydon은 접근성에 대한 작업과 저술로 유명합니다. 그렇다면 "포함하는 디자인"은 실제로 무엇을 의미하며 구성 요소는 어디에서 작동합니까? Heydon은 이 에피소드에서 이 모든 것을 설명합니다. 아래에서 듣거나 팟캐스트를 받을 수 있는 곳이면 어디에서나 구독할 수 있습니다.

메모 표시

• Smashing Magazine의 책 포함 구성요소
• Heydon의 프로젝트 Every Layout with Andy Bell
• Heydon의 웹사이트 Heydonworks
• 트위터의 헤이든

성적 증명서

Drew McLellan: 그는 프리랜서 웹 접근성 컨설턴트, 인터페이스 디자이너 및 작가입니다. 그의 작업은 접근 가능한 사용자 경험 디자인과 Smashing Magazine의 작성 및 편집에 중점을 둡니다. 그는 접근 가능한 웹 응용 프로그램 디자인에 대한 찬사를 받은 책인 Apps For All의 저자이며 Smashing Magazine을 사용하여 접근 가능한 웹 인터페이스를 구축하는 방법에 대한 모든 내용을 담은 새 책 Inclusive Components를 방금 출간했습니다. 그래서 그는 접근 가능한 디자인 주제의 전문가임이 분명하지만, 그가 스피드보트를 타고 시드니 하버 브리지를 뛰어 넘은 최초의 남성이라는 사실을 알고 계셨습니까? 스매싱 친구들이여, 헤이든 피커링을 환영해주세요. 안녕, 헤이든. 잘 지내고 있나요?

헤이든 피커링: 굉장하군 . 저는 브랜드에 있습니다.

Drew: 저는 오늘 귀하의 새 책인 Inclusive Components의 주제에 대해 이야기하고 싶었습니다.

헤이든: 네.

Drew: 분명히 두 단어로 된 제목이지만, 그 단어 하나하나가 많은 힘을 주는 것 같아요. 끝에서 시작하는 것은 분명히 논리적인 구성 요소입니다. 이것은 일종의 구성 요소 기반 설계에 관한 것입니까? 저게 뭐에요?

Heydon: 네, 그래서 사람들, 프론트 엔드 개발자, 디자이너 및 인터페이스를 만드는 데 협력하는 모든 사람들이 구성 요소의 관점에서 생각하고 소화 가능하고 재사용 가능한 소량으로 나누는 것에 대해 생각하기 시작한 지 꽤 된 것 같습니다. 그리고 어떤 이유로 든 작업 방식에 익숙하지 않다면 실제로 전자 부품과 비슷하다고 생각합니다. 아버지는 전자공학자입니다. 그는 회로 기판과 땜납 등의 아날로그 세계에서 일합니다.

Heydon: 사실, 그는 CERN에서 전자석으로 흐르는 전류를 조절하는 데 사용되는 아주 작은 부품 몇 가지를 만들었습니다. 그리고 그는 어렸을 때 저를 많이 믿었습니다. 왜냐하면 그는 제가 실제로 부품의 일부를 납땜하도록 했기 때문입니다. 나는 그 배치가 이제 폐기되었다고 생각하므로 더 이상 CERN에 연루되어 있는 내 열악한 납땜, 열악한 십대 납땜에 대해 걱정하지 마십시오. 하지만 네, 비슷한 것 같아요. ... 오, 거기에 너무 많은 아날로그가 있습니다.

Heydon: 개별 부품이나 구성 요소에 대해 단일 책임을 지고 함께 회로를 만들고 함께 회로의 경우 전류를 증가시킨다는 아이디어라는 점에서 아날로그 회로 기판과 유사합니다. 어떤 방식으로든 인터페이스 또는 결과, 디자인 시스템 또는 디자인 시스템을 통해 나타난 인터페이스. 따라서 포함 구성 요소를 사용하는 이유는 다른 분야에서 우리가 하고 있는 일을 발전시킬 때 일반적으로 접근성이 뒤처지는 경향이 있다는 사실을 다루고 싶었기 때문입니다. 이러한 종류의 새로운 사고 방식과 구성 요소나 모듈 또는 무엇이라고 부르고 싶은지를 사용하여 물건을 만드는 의미, 포괄적인 디자인입니다.

Heydon: 그래서 아이디어는 디자인 시스템에 대한 접근성을 제공하는 것이지만 동일한 토큰으로 접근성 문제를 해결할 때 체계적으로 생각하는 것이었습니다. 접근성 측면에서 한 곳에서 한 종류의 문제를 해결하고 디자인 시스템 전반에 걸쳐 [inaudible 00:03:16] 패턴 주위에 단순히 전파되도록 하는 것에 대해 생각하십시오.

Drew: 일종의 실용적인 의미에서 컴포넌트 기반 방식으로 작동하는 것은 실제로 어떤 모습인가요? 구성 요소의 예는 무엇입니까?

Heydon: 구성 요소를 구상하고 코딩하는 다양한 방법이 있습니다. 저는 개념적인 내용을 지나치고 코드를 구성하는 방법에 대해 생각하는 경향이 있습니다. 저는 실제로 사용자 정의 요소, 또는 사용자 정의 요소가 아닌 경우 일반 요소에 집중하게 되었지만 일종의 격리되고 구성 요소화된 방식으로 해당 요소에 연결된 일종의 JavaScript 동작이 있습니다. 나는 상호 운용 가능한 구성 요소에 대한 아이디어를 정말 좋아합니다. 즉, 다양한 프레임워크와 시스템, 접근 방식 및 기술 스택에서 사용할 수 있습니다. 그리고 커스텀 요소는 네이티브이기 때문에 좋습니다. 한 곳에서 정의한 다음 반응 응용 프로그램에서 사용하거나 보기 응용 프로그램에서 사용할 수 있거나 각도 응용 프로그램에서 사용할 수 있습니다. 사용.

Heydon: 그래서 저에게는 일반적으로 구성 요소가 사용자 정의 요소일 것입니다. 저는 최근에 접근성에 그다지 중점을 두지 않은 프로젝트에서 작업했습니다. 비록 가능한 한 접근 가능하게 만들려고 노력했지만 Every Layout이라고 하는 것은 모두 매우 특정한 종류의 알고리즘을 CSS 레이아웃. 그리고 그것들은 사용자 정의 요소로 정의되며 일종의 자체 배포 및 자체 CSS를 실행하고 더 큰 시스템 내에서 일종의 기본 요소처럼 작동합니다.

Drew: 실제 실용적인 용어로 구성 요소가 양식 필드와 같은 것일 수 있다고 말하는 것입니까?

Heydon: 예, 입력만큼 간단한 것일 수 있습니다. 예를 들어 텍스트 입력과 같거나 탭 인터페이스와 같이 복잡한 것일 수 있습니다. 따라서 포함 구성 요소의 아이디어는 텍스트 입력과 같은 단일 목적을 가진 하나의 구성 요소 개념을 취한 다음 여러 부류의 사람들을 걸려 넘어지게 하고 시도하고 회피할 수 있는 다양한 모든 것에 대해 생각하는 것이었습니다. 그들을. 사람들을 피하지 말고 문제를 피하십시오. 사람을 포함하는 것이 아니라 임의로 사람을 배제하지 않으려는 것입니다.

Heydon: 저에게 포괄적인 디자인 프로세스에 접근하는 가장 쉬운 방법은 무언가의 잠재적인 배제 요소를 식별하고 이를 우회하는 것입니다. 따라서 레이블이 있는 텍스트 입력을 사용하면 걱정할 수 있는 여러 가지 사항이 있습니다. 따라서 처음에는 실제로 올바르게 레이블이 지정되었는지 여부를 알 수 있습니다. 그래서 레이블 요소를 사용하고 있고 해당 레이블 요소가 for 속성을 사용하여 텍스트 필드를 가리키고 있으므로 두 가지가 프로그래밍 방식으로 연결되어 화면 판독기 사용자가 입력에 초점을 맞출 때 실제로 레이블이 발표되는 소리를 들을 수 있습니까? 그래서 바로잡아야 할 한 가지입니다.

Heydon: 그런 다음, 좀 더 시각적인 수준에서 레이블이 다른 필드가 아니라 해당 필드와 명확하게 연관되어 있는지 확인합니다. 그것은 공백과 그런 종류의 문제입니다. 또한 레이블이 없는지 확인하면 양식 입력 아래에 레이블을 두는 것과 같은 멋진 작업을 수행하지 않습니다. 예를 들어 가상 키보드가 표시될 때 레이블이 가려질 수 있기 때문입니다. 그래서 그런 것들을 고려하고 있습니다.

Heydon: 입력 자체에 포커스 스타일이 있는지 확인하여 키보드로 포커스를 맞출 때 키보드를 사용하여 탐색하는 습관적인 키보드 사용자인지 여부에 관계없이 포커스 스타일에서 그것이 무엇인지 명확히 하십시오. 당신이 집중하고 있는 입력. 자동 완성과 같은 것을 확인하고 자동 완성이 맥락에서 적절하고 도움이 되는지 여부에 대해 걱정합니다. 그리고 이러한 것들 중 많은 것들이 장애를 직접적으로 다루지만, 그들 중 많은 것들은 사용성 측면에서 좀 더 광범위하고 가능한 한 이해하기 쉽게 만듭니다.

Heydon: 아주 자주, 모든 사람을 위한 사용성을 다루는 것과 장애를 다루는 것 사이에 아주 미세한 선이나 아마도 모호한 선이 있습니다. 그런 다음, 인지 장애를 파악하기가 훨씬 더 어렵습니다. 따라서 인지 장애가 없는 사람에게 그다지 유용하지 않은 것이 있다면, 그러한 문제가 있는 사람에게는 운동을 하고 사용할 수 있는 것이 훨씬 더 어려워질 것입니다.

Heydon: 그래서 한 곳에서 모든 것을 생각하려고 하는 것입니다. 그리고 정말로, 이 책은 단지 나의 것, 내가 그것들 각각에 접근할 때의 나의 사고 과정입니다. 그래서 처음에는 블로그로 했습니다. 그리고 각 패턴 또는 각 구성 요소는 블로그 게시물이고 텍스트는 "이제 잠재적인 문제를 해결해 보겠습니다. 어떻게 해야 할까요? 좋아요, 우리는 그것을 확인했습니다. 거기에 우리는 괜찮은 것 같아요.” 그리고 결코 이것이 완벽하고 불가능하기 때문에 모든 것을 생각해 봤다고 말하려는 것은 아닙니다.

Drew: 인터페이스의 개별 부분에서 작업하는 방법에 대한 구성 요소 기반 접근 방식을 취하는 것도 마찬가지입니다. 제 생각에는 특정 항목에 대해 깊이 있게 접근할 수 있고 최상의 방식으로 최적화했는지 확인할 수 있습니다. 모든 사람이 액세스할 수 있도록 할 수 있습니다. 그렇게 하고 많은 다른 구성 요소에서 그렇게 한 다음 모든 구성 요소를 한 페이지에 모으는 데 위험이 있습니까? 함께 테스트하지 않고 개별적으로 테스트하기 때문에 미처 알지 못했던 문제가 발생할 수 있는 위험이 있습니까?

Heydon: 정말 좋은 지적입니다. 사실 더 일찍 언급하려고 했습니다. 그렇게 말씀해주셔서 기쁩니다. 그래서 여러 면에서 철학적으로 우리는 사물을 개별 구성요소로 분리해야 한다고 결정했다고 생각합니다. 그리고 그렇게 하는 것에는 미덕이 있습니다. 왜냐하면 그것이 고립되어 있다면 일종의 테스트와 일종의 단일 것으로 취급하는 것이 더 쉽기 때문입니다. 그리고 우리가 일하는 방식의 관점에서 보면 일을 더 쉽게 관리할 수 있습니다. 우리는 또한 이러한 것들이 궁극적으로 같은 공간을 공유하고 더 큰 시스템으로 결합되어야 한다는 사실도 고려해야 합니다.

Heydon: 그리고 실제로 우리의 노력과 생각이 충분히 재미있다고 생각하지 않습니다. 우리는 엔지니어로서의 삶을 더 쉽게 만들기 위해 더 많은 것을 구성 요소화하여 우리가 언제 작업하고 있는지 알 수 있다고 생각합니다. 그리고, 그러나 우리는 종종 이러한 것들이 역동적인 시스템에 존재할 것이라는 사실을 무시합니다. 그리고 그들은 …

Heydon: 내 말은, Every Layout 프로젝트는 시각적 디자인과 레이아웃에 관한 것이긴 하지만 이 작은 CSS 프리미티브, 이 작은 레이아웃 프리미티브를 일종의 알고리즘 방식으로 자체 관리할 수 있는 방식으로 만들려는 것입니다. 좁은 열에서 꺼내서 넓은 열에 놓으면 코드 자체에서 나란히 있어야 하는 항목 수 또는 다른 방식으로 재구성해야 하는지 여부를 결정합니다. 우리는 끊임없이 개입할 여유가 없고 일종의 자의식과 지능적인 시스템이어야 한다고 생각합니다.

Heydon: 항상 잊어버릴 수 있는 것들이 있습니다. 따라서 탭 인터페이스를 만들고 탭 행이 있고 탭 사이에서 선택하고 탭은 탭 패널에 해당하여 무언가를 여는 것입니다. 그런 다음 누군가가 와서 "탭 인터페이스를 탭 인터페이스 안에 넣거나 탭 인터페이스 안에 다른 구성 요소를 넣으면 어떻게 될까요?"라고 말할 것입니다.

Heydon: 그리고 물론, 그것이 가능한지 여부에 대한 부분적으로는 기술적인 문제지만, 네, 가능한 한 유연하게 할 것인지에 대한 선택을 해야 합니다. 복잡한 방식으로 사물을 혼합하거나 단순히 다음과 같은 어려운 규칙을 작성하는 것이 가능합니다. 사용자가 사물을 인식하고 사용할 수 있는 방법." 저는 "복잡한 기능을 내부에 많이 중첩하지 마십시오"라는 규칙을 작성하는 데 찬성합니다. 왜냐하면 사람들이 실제로 그것에 대해 머리를 숙일 가능성이 거의 없기 때문입니다.

Drew: 접근성을 위한 설계에 완전히 알고리즘적 또는 자동화된 접근 방식을 취할 수 있습니까?

헤이든: 난 그렇게 믿지 않아. 아니요. 그래서 우리는 자동화된 도구를 가지고 있으며 자동화된 도구를 어떤 식으로든 폄하하고 싶지 않습니다. 나는 그것들이 매우 유용하다고 생각하지만, 문제 영역이 어디에 있는지에 대한 인상을 얻기 위해 일종의 조기 경보 시스템처럼 사용합니다. 따라서 제품을 보다 쉽게 ​​액세스할 수 있도록 하는 방법에 대한 조언을 원하는 조직을 위해 감사를 수행하는 경우였습니다. 따라서 문제 영역이 있는 곳에 자금을 제공하는 좋은 방법입니다. 하지만 기술적으로 100% 액세스할 수 있는 인터페이스를 가질 수 있습니다. 아마도 일부 도구에 따르면 WCAG에 대해 판단하는 좋은 도구일 수도 있습니다. , 웹 콘텐츠 접근성 지침 또는 기타 수락 사양. 그리고 모든 체크박스가 100% 체크되어 있어도 여러 가지 이유로 완전히 사용하지 못할 수 있습니다.

Heydon: 예를 들어, 이전에 말했던 것으로 돌아가면 완전히 너무 복잡할 수 있습니다. 링크로 누군가를 압도할 수 있고 그들이 그것을 통과할 수 있는 방법은 없습니다. 그러면 그것은 일종의 암묵적인 일이고 고정하기 어려운 것이 되지만 사람들을 소외시킬 수밖에 없습니다. 하지만 오탐(false positive)과 같은 것을 얻는 것은 매우 쉽습니다. 요전날 일이 있었는데, 요전날, 요전날, 나는 조직에서 일하고 있었고 물론 그들은 100% 접근성 등대 학교를 갖고 싶어했고 거기에 동적으로 드롭된 iframe이 있었습니다. 분석 스크립트 또는 무언가에 의해. 당신은 그것이 일종의 약간 조잡한 코드인 것을 알고 있습니다. 그것은 그런 작업을 수행하기 위해 페이지에서 일종의 척입니다.

Heydon: 이제 분석을 전혀 사용하지 않는 것이 좋으며 사람들이 선택 해제할 수 있도록 최소한 추적 금지 프로토콜을 지원하도록 권장했습니다. 불행히도 그 프로토콜은 실제로 제대로 지원되지 않았기 때문에 더 이상 실제로 작동하지 않습니다. 그러나 이 iframe에는 제목이 없다고 했습니다. 그래서 아이디어는 iframe이 있는 경우 스크린 리더 사용자가 iframe이 무엇인지 식별하는 가장 오래된 방법이기 때문에 제목 속성이 있어야 한다는 것입니다. 그러나 이것은 또한 아무 것도 표시하지 않도록 설정된 iframe이었기 때문에 화면 판독기에서 시각적으로 사물을 숨기는 것과 마찬가지로 화면 판독기에서 본질적으로 제거됩니다. 인터페이스이므로 어떤 식으로든 만나거나 발표되지 않습니다.

헤이든: 그래서 그것은 거짓 긍정이었습니다. 내 말은, 애초에 인식할 수 없는 iframe을 식별해 달라는 것이었습니다. 따라서 자동화된 테스트에는 항상 이러한 종류의 오류와 문제가 있습니다. 그러나 궁극적으로 그것은 아는 것에 관한 것입니다. 비록 프로그래머가 일종의 일이지만, 제 생각에는 프로그래머가 자신이 관련되어 있다고 생각하는 것을 별로 좋아하지 않고 약간 이상하다고 생각하지만 인간의 행동에 관한 것입니다. 사람들이 사물을 이해하는 방법과 그것은 일종의 이진법 또는 부울 형식의 규칙 집합을 갖는 것은 매우 어려운 일입니다.

Heydon: 그래서, 내 말은, 내가 얼마 전에 이것에 대해 컨설팅을 할 때 개발자와 이야기를 나누었고 그들은 계속 말했습니다. 그냥, 우리는 앞으로 나아갈 수 있습니다.” "여전히 수동으로 테스트해야 합니다. 키보드로 인터페이스를 사용하는 것이 어떤 식으로든 불가능한지 여부를 알려줄 수 있는 자동화된 테스트는 없습니다.” 당신이 찾을 수 있는 이산적인 것들이 있지만 전반적인 경험은 여전히 ​​인간이 판단해야 하는 것입니다. 응.

Drew: 때때로 자동화 도구의 위험은 개별 항목을 보거나 하나의 인터페이스를 개별적으로 보고 더 넓은 컨텍스트를 보지 않는다는 것입니다.

헤이든: 네.

Drew: 확실히 성능 감사를 위해 등대를 사용하면 때때로 개발자로서 포함하기로 결정할 수 있습니다. 한 페이지에 사용되는 것보다 훨씬 더 많은 CSS가 있을 수 있고 엄밀히 말하면 너무 많은 CSS를 다운로드하고 있지만 실제로는 , 해당 파일이 로드되면 사용자가 다음 페이지를 탐색할 때 이미 CSS가 있다는 것을 알고 있습니다. 따라서 도구는 여러 페이지에 걸쳐 수행되는 최적화이며 한 페이지를 분리하여 보고 오류로 간주합니다.

헤이든: 네, 물론입니다. 당신은 미리 생각하고 판단을 내리고 있습니다. 고급 AI가 이를 예상할 때까지 그렇습니다. 인간이 그것을 보고 통과하고 진행하는 것이 정말 필요합니다... 제 말은, 자동화된 테스트는 제가 말했듯이 일종의 조기 경보 시스템, 진단 시스템이 있어야 합니다. 하지만 조직이 진정으로 관심을 갖고 보다 포괄적이고 접근하기 쉽게 만드는 데 관심이 있다면 교육도 필요합니다. . Q&A가 있어야 합니다.

Heydon: 그래서 저는 "이것이 키보드로 이 구성 요소와 상호 작용할 때 작동하는 방식입니다." 또는 "실제로 단계별 실행이 아니라 스크린 리더와 상호 작용할 때 작동해야 하는 방식입니다. 그것. 그래서, 당신이 이것을 할 때, 이것은 일어나야 합니다. 이렇게 하면 이런 일이 일어나야 합니다. 이 작업을 수행하면 이것이 나타나야 합니다.” 또는 그런 종류의 것입니다. 따라서 자동화된 도구는 이를 인식하지 못합니다. 그들은 단지 "오, 여기에 대체 텍스트가 없습니다."라고만 봅니다. 그리고 실제로 많은 경우에 대체 텍스트가 없어야 합니다. 또한 대체 텍스트를 잘 작성했는지 여부를 판단할 수 없습니다. 그래서 나는 모든 대체 텍스트가 없는 이미지가 오해의 소지가 있거나 잘못된 대체 텍스트가 있는 이미지보다 더 낫다고 생각합니다. 그리고 그것은 다시 심판을 부르는 것입니다. 그렇지 않습니까?

Drew: 역사적으로 접근 가능한 방식으로 사물을 구축하는 데 어려움을 겪었던 것 중 하나는 모범 사례에 대한 지식을 최신 상태로 유지하는 것입니다. 내가 하고 있는 것과 내가 옳은 일을 하고 있다고 생각하는 것 같으며, 권장 사항이 계속 진행되었으며 이제 다른 일을 해야 합니다. 이는 웹 작업의 모든 영역에 대한 익숙한 이야기입니다. 하지만 제 생각에는 물론 접근성 문제의 위험은 모범 사례를 따르지 않고 인터페이스에 현재 모범 사례가 아닌 무언가를 남겨두면 사용자에게 부정적인 영향을 미칠 수 있다는 것입니다. 방법. 인터페이스나 사이트를 구축하기 위한 구성 요소 기반 접근 방식이 어떤 식으로든 도움이 됩니까?

Heydon: 순전히 하나의 구성 요소가 있기 때문에 접근성 측면뿐만 아니라 모든 경우에 대한 아이디어는 이 구성 요소를 한 곳에서 정의한 다음 다른 곳에서 사용할 수 있다는 것입니다. 최소한 측면이나 브라우저가 지원하거나 그것이 무엇이든 변경되고 구성 요소를 업데이트하려는 경우 한 곳에서만 업데이트를 수행하고 사용되는 모든 위치에서 개선 사항이나 변경 사항을 느낄 수 있습니다. 그런 면에서 저는 확실히 물건을 구성요소로 나누는 것이 더 유용하다고 생각합니다.

Heydon: 하지만 내가 말했듯이 그것은 접근성에만 영향을 미치는 것이 아니라 변경되는 모든 것에 영향을 미칠 수 있습니다. 하지만 실제로 얼마나 많은 변화가 있는지는 잘 모르겠습니다. … 제 말은, HTML 접근성 측면에서 획기적인 변화가 거의 없을 것입니다. 이는 분명히 매우 좁은 영역입니다. 그러나 코드 품질이나 코드 작동 방식 면에서 HTML 사양에 매우 천천히 그리고 ARIA 사양에도 아주 느리지는 않지만 상당히 천천히 도입됩니다. 그리고 ARIA의 대부분은 어쨌든 기본 HTML에 있는 내용을 그대로 반영합니다.

Heydon: 제 생각에는 기술보다 이러한 것들에 대한 인식과 이해가 시간이 지남에 따라 변하는 경향이 있습니다. 내 말은, 최근 WebAIM 설문 조사에서 ARIA를 사용하는 사이트가 사용하지 않는 사이트보다 액세스하기 어렵다는 것을 확인했습니다. 그래서 사람들이 웹사이트에 더 쉽게 접근할 수 있도록 돕기 위해 특별히 고안된 이 기술은 상황을 악화시켰습니다. 기술 격차나 기술 부족이 아니라 지식 격차일 뿐입니다. 불행히도 실제로 어떻게 작동하는지 이해하지 못했기 때문에 사람들이 기술을 사용하고 오용하는 것입니다. 제 글이 조금이나마 도움이 되었으면 합니다. 어쨌든 일부 지역에서는.

Drew: 하지만 일종의 잘 구성된 구성 요소 기반 시스템을 통해 무언가가 구식이라는 것을 깨닫거나 잘못된 결정을 내렸고 이제 더 잘 알게 되면 더 쉽게 들어가서 수정할 수 있습니다. 애플리케이션 전반에 걸쳐.

헤이든: 네, 맞습니다. 예, 예, 절대적으로. 내 말은, 모든 것이 효율성에 관한 것입니다. 그렇지 않습니까? 그리고 이 무미건조한 원칙 또는 여러분이 가지고 있는 것, 그래서 제가 원래 이 기회에 대해 매우 흥분했던 것 같습니다. 사람들은 항상 사물을 접근 가능하게 만드는 것은 추가 작업이고 힘들고 속상한 일이라고 불평하기 때문입니다. 그래서 이렇게 말할 수 있는 기회가 생겼습니다. 만들고 있는 하나의 구성 요소에 대한 접근성을 확보하면 간헐적인 사양 변경이나 업데이트를 제외하고 더 이상 접근성에 대해 걱정할 필요가 없습니다.”

Heydon: 아니면 대부분의 경우 반복 작업은 단순히 사용자 피드백과 지속적인 연구를 기반으로 할 것이며, 분명히 가능한 한 다양한 그룹의 사람들과 함께 수행해야 합니다. 따라서 다른 장치를 사용하고 검색 습관이 다르며 보조 기술과 같은 것을 사용하는 사람들을 확보해야 합니다. 그리고 당신도 알다시피, 상황은 항상 일어나기 마련입니다. 구성 요소를 확실히 고정하고 정말 견고하다고 생각하고 약간의 조사를 해보니 꽤 잘못된 가정을 했다는 것을 알게 되었습니다. 그러나 예, 구성 요소 시스템을 사용하면 한 곳에서만 수정하면 됩니다.

Drew: 구성 요소가 완전히 포괄적일 수 있습니까? 아니면 포함을 위해 더 많은 노력을 기울이고 있는 스펙트럼입니까?

Heydon: 예, 구성 요소가 WCAC 오류가 없다고 하면 모든 WCAC 기준을 충족할 수 있습니다. 이러한 기술적 기준을 충족하더라도 이해할 수 없습니다. 예, 이것은 제가 많이 이야기하는 것입니다. 저는 사람들에게 접근성은 다른 디자인 영역과 마찬가지로 디자인 프로세스의 일부일 뿐이며 완벽하게 접근할 수 없는 것처럼 완벽하게 디자인될 수는 없다는 것을 설득하려고 노력합니다. 불행히도 많은 사람들이 스크린 리더와 호환되는지 확인하는 차원에서 생각한다고 생각합니다. 이는 일반적으로 접근성 및 포함 측면에서 분명히 매우 좁은 범위입니다.

Heydon: 그렇다면 Paciello Group과 같이 나와 함께 일했던 좋은 사람들이 "음, 사실 저는 접근 가능한 UX 담당자로 알려지고 싶어요."라고 말할 것입니다. 따라서 이것은 단지 이 상자를 확인하는 연습에 관한 것이 아니라 더 많은 사람들을 위해 경험을 더 좋고 가치 있게 만들고 일종의 더 넓은 원칙과 덜 이분법적인 것을 향해 나아가는 것에 관한 것입니다. 그러나 궁극적으로, 그것이 전부이며 WCAC 및 기타 그러한 기준은 "이것은 잘못되었습니다."

Drew: 그렇다면 내가 개발자라면 구성 요소를 디자인하고 계획하고 구축하는 방법에 접근할 때 다르게 해야 할 일은 무엇입니까? 해당 구성 요소가 가능한 한 포괄적이 되도록 하기 위해 내 작업에서 고려해야 할 사항이 있습니까?

Heydon: 그래서, 당신이 무엇을 만들고 있느냐에 따라 충족되어야 하는 다른 기준이 있을 것입니다. 예를 들어, 이미지를 전혀 사용하지 않을 수 있기 때문에 모든 구성 요소에 대체 텍스트가 있는 액세스 가능한 이미지가 있어야 하는 것은 아닙니다. 그것은 단지 텍스트 기반이거나 당신이 가지고 있는 것일 수 있습니다. 일부는 인터랙티브하지 않을 수 있습니다. 따라서 특정 요구 사항의 측면에서 구성 요소 간에 변경될 수 있지만 제 글과 포함 구성 요소 책이 도움이 되는 것은 포괄적으로 생각하는 원칙에 빠지거나 일종의 채택하는 것입니다.

Heydon: 따라서 이 문제에 접근할 때 단순히 생각하는 것이 아니라 기본적으로 "나에게 효과가 있다면 다른 모든 사람에게도 효과가 있을 것입니다"라는 사고방식에서 벗어나는 것입니다. 당신이나 내가 물건을 탐색하는 방식, 내 말은, 우리는 아마도 완전히 다르게 일을 할 것입니다.

드류: 맞아.

헤이든: 그리고 우리는 서양인, 백인, 영어를 모국어로 사용하는 사람들입니다. 그래서, 네, 이것을 소비하는 사람들의 관점에서 다양성의 양, 제 말은 성능 사람들은 항상 이것에 대해 이야기합니다. 더 나은 성능을 옹호하는 데 관심이 있는 사람들입니다. 당신은 좋은 네트워크에서 높은 사양 설정을 사용하는 데 익숙하고 많은 사용자 또는 많은 잠재적 사용자는 확실히 그렇지 않을 것이며 접근성도 동일합니다. 기본적으로 자신에 대해 생각하는 것에서 벗어나는 것에 대한 질문입니다. 말 그대로 그냥. 그리고 분명히, 당신의 직계 동료와 같은 사회 집단에 있는 사람들을 넘어서 접근하려고 노력합니다.

Heydon: 그래서 바라건대, "여기에 내가 이 문제를 해결한 것이 있습니다." 그리고 당시에 내가 생각하고 있던 것이 있습니다. 그 아이디어 중 일부를 재사용하고 내가 적용한 것을 정확하게 적용할 수 있습니다. 유용하거나 관련이 있는 경우입니다. 바라건대, 이 책은 “여기 포용적으로 생각하려고 노력하는 사람의 사례 연구가 있습니다. 보세요, 그들이 생각하고 있던 종류, 완전히 다른 것을 디자인할 때 아마도 같은 종류의 생각을 사용하고 다양한 사용자와 그들이 일을 처리하는 방식에 마음을 열도록 노력하십시오.”

드류: 그래서 책 자체가 어떻게 구성될지 어떻게 결정하셨나요? 제가 책에서 좋아하는 내용인데, 어떻게 구성하셨나요?

Heydon: 이전 책과 매우 흡사하게 Inclusive Design Patterns였습니다. 처음에는 그 책을 일종의 추상적인 기준으로 정리하려고 했기 때문에 그 책을 시작하는 데 많은 어려움을 겪었습니다. 그래서 저는 키보드 접근성에 관한 모든 챕터를 시작했지만, 그 당시에는 다른 유형의 키보드 접근성이나 여러분이 생각해야 할 것에 대해 이야기할 때마다 일종의 어떤 종류의 구성 요소를 생성한 다음 해당 구성 요소를 버리고 다른 것으로 이동해야 했습니다.

Heydon: 그래서 구성 요소 자체 측면에서 정리하는 것이 더 합리적이었습니다. 따라서 포괄적인 디자인 패턴이 이 작업을 수행하고 이제 포함된 구성 요소는 실제로 다른 구성 요소를 다루는 연속체일 뿐입니다. 라이브 코드 예제와 내용도 포함하고 있기 때문에 기능 면에서 조금 다릅니다. 이전 책에서는 그렇게 많이 하지 않았습니다. 하지만 네, 탭 인터페이스든 접을 수 있는 섹션이든 테마 스위처든 알림 플래시 카드든 토스터든 무엇이라고 부르든 말 그대로 "우리는 이 구성 요소를 할 것입니다." 그런 다음 해당 구성 요소를 중심으로 구성됩니다.

Heydon: 그래서 "이것이 우리가 하고 있는 일이며 더 포괄적인 일을 하기 위해 이 일을 하는 동안 고려해야 할 사항입니다." 그것이 내가 일하는 방식이고 다른 사람들이 일하는 방식이기 때문입니다. 그리고 그렇게 하기 시작하자마자 정말 나 혼자 일하면서 노트를 쓰고 있었다. 그래서, 그것은 일종의 자체적으로 작성되었고, 모든 노력은 실제로 내가 그런 것들을 액세스할 수 없도록 만드는 적절한 일을 하고 있는지 확인하는 것이었습니다.

Drew: 네, 제 말은 목차가 실제로 거의 문서나 자조 매뉴얼 같은 것으로 읽힌다는 뜻입니다. 챕터 1, 토글 버튼으로 바로 시작합니다. 일부 토글 버튼을 구현하고 싶다면 이 장으로 이동하여 읽어보세요. 그렇게 하는 방법에 대해 알아야 할 모든 것을 얻을 수 있습니다. 이는 제가 정말 좋아하는 접근 방식입니다. 접을 수 있는 섹션, 탭이 있는 인터페이스, 테마 스위치, 데이터 테이블, 우리 모두가 매일 구축하고 있는 실제적이고 실제적인 것들과 같은 것들을 볼 수 있으며 아마도 우리 모두가 더 잘 구축할 수 있을 것이라고 생각합니다.

Heydon: 네, 그건 전적으로 아이디어였습니다. 왜냐하면 제가 구성 요소를 만드는 것뿐만 아니라 케이스였고, 거기에 손을 대셨기 때문에 기쁩니다. 우리 모두가 사용하는 패턴. 그래서 제 말은, 탭 인터페이스가 어디에나 있고 그것들은 모두 다르게 구현되고 그것들은 모두 다양하고 매우 나쁘게 구현된다는 것입니다. 제 말은, 저는 끔찍한 탭 인터페이스를 구현했고 그것이 사람들에게 얼마나 나쁜지 조금 배웠고, 그 다음에는 그것들을 조금 더, 조금 더 좋게, 조금 더 좋게 만들려고 노력했습니다. 나는 아마 내 시간에 15 또는 16가지 다른 버전의 탭 인터페이스를 만들었고 지금까지 몇 년 동안 이런 일을 해왔습니다.

Heydon: 그리고 알다시피, 그들은 매번 조금씩 나아지고 있습니다. 그러나 그것은 단지 일반적인 일입니다. 그것은 내가 사용하는 다른 웹 사이트 사이에서 꽤 자주 사용하는 공통된 것입니다. 그래서 아이디어의 일부는 "글쎄, 사실, 웹을 위한 접근 가능한 디자인 시스템의 일종인 디자인 시스템을 해보자."라고 말하는 것이었습니다. 이제 사람들은 가지를 뻗고 이러한 것들의 고유한 버전을 만들 것입니다. 그러나 일종의 핵심적인 내용을 파악하고 접근성은 사물에 있어야 하는 핵심적인 것입니다. 추가 기능이 되어서는 안 되며, 기능이 되어서도 안 됩니다. 핵심이 되어야 합니다. 그리고 핵심 내용을 짝지어 놓으면 사람들이 챕터를 보고 "아, 알겠습니다. 제가 만들었습니다. 나는 그것들을 보았다. 가능한 한 포괄적으로 수행하는 방법을 봅시다.” 그런 다음 희망적으로 그들은 그로부터 어떤 가치를 얻습니다.

Drew: 글쎄요, 제가 좋아하는 점은 과거에 구현해야 하는 몇 가지 인터페이스 기능이 있다는 것과 접근성 관점에서 이것이 까다로울 것이라는 점을 확실히 압니다. , 일종의 플라이아웃 메뉴, 드롭다운 메뉴 등을 말합니다. "좋아요, 접근성 측면에서 드래곤이 있습니다. 내가 이 일을 제대로 하고 있는지 확인해야 합니다.” 그래서 구글에서 그 방법을 찾아보고 "이 방법을 사용하세요"라는 평판이 좋은 출처를 찾았습니다. 그 방법을 사용하고 구현하고 계속 진행하지만 실제로는 배운 것이 없습니다. 나는 그 해결책이 왜 그런 것인지 배우지 못했다. 그리고 책에서 당신이 그것에 들어가는 방식에 대해 내가 정말 좋아하는 것은 한 번에 두 가지 일을 할 수 있다는 것입니다. 어떻게 해야 하는지 알 수 있고 왜 그렇게 해야 하는지도 너무 자세히 설명되어 있기 때문에 알 수 있습니다. 그런 면에서 정말 성공적인 것 같아요.

헤이든: 오, 좋아. 그게 내가 하려는 것이었습니다. 그래서 좋습니다. 하지만 네, 그게 제 몫인 것 같습니다. I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. 응.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.