Olutimilehin Olushuyi는 접근성 분야를 처음 접하는 변호사입니다. JavaScript와의 싸움, 국제 표준, 웹사이트 콘텐츠 읽기의 중요성에 관해 이야기했습니다.
이 게시물은 접근성 학습의 일환으로 커뮤니티 전문가를 소개합니다.
알렉산드라 클레퍼: 웹 접근성을 어떻게 시작하게 되었나요?
Olutimilehin Olushuyi (Shuyi): 네, 재미있는 이야기입니다. 저는 변호사입니다. 학교 마지막 해에 남은 인생 동안 법을 연습하고 싶지 않다는 것을 깨달았습니다. 그래서 학교를 그만두려고 했지만 학장님과 '학교 어머니'인 아요델레 아체누와 교수님이 '이 문제에 대해 이야기해 보자'라고 말씀하셨습니다. 마지막 해니까 그냥 끝내'라고 말합니다.
결론적으로는 그 말을 해 줘서 기쁘고, 내가 끝내서 기쁩니다. 접근성 작업에 도움이 되었기 때문입니다. 아체누와 교수는 대신 무엇을 하고 싶은지 물었지만 저는 아무것도 떠오르지 않았습니다.
새로운 경력 기회를 찾아보기 시작했고, 스타트업을 만들고 변호사가 필요한 사람들과 연락을 취했습니다. 그 기회는 적합하지 않았지만, 우리가 사용하는 모든 제품을 위해 사람들이 코드를 작성한다는 것을 처음 알게 되었습니다. '이거라면 할 수 있어'라고 생각했어요. HTML과 CSS를 독학하기 시작했습니다. 그러다 JavaScript를 접하게 되었는데... [웃음] JavaScript가 JavaScript 작업을 수행했으므로 프런트엔드 시맨틱 언어에 다시 집중했습니다.
Andy Bell과 Heydon Pickering의 작업을 접하게 되었습니다. Every Layout을 구매했는데, 제 인생이 바뀌었어요. 앤디는 접근성을 계속 언급했지만 이 맥락에서 접근성이 무엇을 의미하는지 몰랐습니다. JavaScript를 작성하는 방법을 몰라도 웹 개발을 할 수 있다는 것을 알게 되었습니다.
Heydon에게 연락했는데 매우 수용적이고 응답도 빨랐습니다. 접근성 분야의 모든 사람이 그런 것 같아서 감사하게 생각합니다.
Alexandra: 저도 동의합니다. 제가 대화를 나눈 모든 분들이 친절하고 도움이 되었습니다.
수이: 물론입니다. 현재는 옹호 활동을 훨씬 더 많이 하고 있습니다. 나이지리아에 거주하고 있으며, 이 국가에서는 웹 접근성이 법으로 의무화되어 있지 않습니다. 장애인 차별 금지법은 2018년에 통과되었습니다. 하지만 웹 접근성 관련 법은 없고 물리적 접근성 관련 법만 있습니다. 미국의 장애인 보호법 (ADA)과 유사합니다. 우리 법은 구조가 좋지 않지만 없는 것보다는 낫습니다.
변화를 만들고 접근성에 중점을 둔 개발자가 되려면 먼저 생태계에서 접근성 요구사항을 인식해야 한다는 것을 깨달았습니다. 접근성 옹호에 관한 트윗을 시작했습니다. 접근성을 구현하려면 동의가 필요한 회사 및 브랜드와 이야기를 나눴습니다.
Alexandra: 법률 관련 배경이 접근성 관련 업무에 매우 유용할 것 같아요. 실제로 새로운 법률을 읽고 일반인이 이해하지 못하는 방식으로 이해할 수 있습니다. 여기에는 일반적인 개발자가 포함됩니다.
Shuyi: 법률 분야에서 일한 덕분에 지루함 없이 배경 자료, 긴 문서 등을 끝까지 읽을 수 있게 된 것이 가장 큰 선물인 것 같습니다. 다리를 접고 노트북을 올려놓고 읽기 시작합니다. 읽기 읽기 장점도 있습니다.
Alexandra: 부럽네요. 정말 좋은 기술이에요. 정부와 협력하여 디지털 접근성 관련 법률을 통과시킬 의향이 있나요?
수이: 솔직히 말해 그렇게 생각하지 않습니다. 정부와 소통하는 것은 완전히 다른 문제입니다. 정부가 무언가를 하도록 하는 데 너무 오래 걸립니다. 특히 개인의 경우 더욱 그렇습니다. 이러한 종류의 작업은 변화를 가져올 수 있는 인력과 리소스가 있는 NGO 및 기타 조직에 더 적합합니다.
물리적 법률이 통과되는 데 너무 많은 시간이 걸렸고, 접근성 요구사항은 몇 년 전 법률에 포함된 것보다 훨씬 더 발전했습니다. 세상이 바뀌었음에도 불구하고 첫 번째 초안이 통과된 것과 같습니다.
결과적으로는 아무리 오래된 정보라도 의지할 수 있는 정보가 있다는 점이 다행입니다. 시행해야 할 법이 있습니다.
접근성 높은 레이아웃 만들기
Alexandra: Smashing Magazine에서 <article> 대 <section>: 올바른 항목을 선택하는 방법이라는 기사와 이 기사에 영감을 준 트위터 스레드를 읽었습니다. 가장 큰 수확은 무엇이며 웹 개발자에게 바라는 점은 무엇인가요?
Shuyi: 개발자는 레이아웃 빌드를 시작하기 전에 콘텐츠를 읽어야 합니다.
원래 사이트 디자인에서는 단락 수를 세어 섹션과 아티클에 넣기만 했고, 별로 생각하지 않았습니다. 하지만 누군가 섹션의 오용에 대해 알려주었고 그때 처음으로 이 문제를 생각하게 되었습니다. 콘텐츠를 읽는 것은 더 나은 제품을 만들기 위해 할 수 있는 일 중 하나입니다.
Alexandra: 개발자 시절에 프리랜서 고객이 '일단 뭔가 만들어 주시면 나중에 콘텐츠를 채울게요'라고 말하는 경우가 많았습니다. 물론 연락처 페이지와 같이 자동 컨텍스트가 있는 페이지도 있습니다. 하지만 빌드해야 하는 페이지 수와 필요한 맞춤 지원의 종류는 콘텐츠를 받아야만 알 수 있었습니다.
수이: 지금의 지식을 알기 전에는 최고의 클라이언트가 일반적인 디자인 아이디어를 제공하면 제가 lorem ipsum을 많이 사용하여 사이트를 구축했습니다. 내가 알아낼게. 하지만 콘텐츠 인프라가 웹 사용자에게 얼마나 큰 영향을 미치는지 알게 되면 웹에서 항목을 빌드하는 표준 프로세스에 얼마나 많은 결함이 있는지 알게 됩니다. 무언가를 만들 때는 의도적으로 해야 합니다.
접근성 인프라 작업은 전혀 주목을 받지 못해 마음이 아픕니다.
Alexandra: 도움말에 제공된 조언이 올바른지 확인하기 위해 어떤 조사를 하셨나요?
수이: 먼저 정보의 출처를 구분했습니다. 법률에서 1차 출처와 2차 출처를 구분하는 것과 같습니다. 기본 소스는 실제 법률 (예: ADA 및 나이지리아 법률)이고 보조 소스는 전문가가 법률에서 해석한 내용입니다.
HTML, WCAG, WAI-ARIA 사양과 같은 기본 소스만 참조하기로 했습니다. 다른 사람의 작품을 읽는데, 좋은 작품이 많아요. 하지만 결국 의견이 너무나도 달라서 유용한 맥락으로만 받아들이고 올바른 답이 있다고는 생각하지 않기로 했습니다.
접근성 높은 커뮤니티 구축
Alexandra: 트위터 피드를 접근성 공간으로 만들려고 하셨다고 언급하셨습니다. Smashing Magazine에 기사가 게시된 후 트위터에서 학습한 내용에 관해 다른 대화를 많이 나누셨나요?
수이: 처음 며칠 동안은 트위터를 제대로 이해할 수 없었어요. 200명 넘는 사람들이 저를 팔로우했어요. 처음에는 신났지만 나중에는 무서웠어요. 이제 막 시작한 단계라 현명한 조언을 기대하지는 마세요. 트위터 목록에 많이 추가되었습니다.
하지만 저는 사람입니다. 접근성, 웹 개발자가 아닌 모호한 내용에 관한 트윗을 많이 올립니다. 사람들을 실망시키고 싶지 않아요. 접근성 때문에 팔로우하지 마세요. 실망시켜 드린 것 같아 죄송한 마음이 들어요.
Alexandra: [웃음] 많은 사람들이 그렇게 생각하는 것 같아요. 트위터 페르소나에 대해서는 확실히 그렇습니다.
수이: 기사 자체에 대한 대부분의 반응은 긍정적이었습니다. 약간 논란의 여지가 있는 도움말에 대한 응답을 하나 받았습니다. 내 편집자인 Vitaly가 직접 연락하여 댓글을 공유하고 조사를 요청했습니다. 이 사람은 모든 문서에 제목 요소가 있어야 한다고 명시된 MDN 문서를 참고한 것으로 밝혀졌습니다. 사양에 따라 섹션에 제목 요소가 있어야 한다고 추천했습니다.
MDN 문서에서는 헤더를 포함하도록 권장하지만 그 이점을 제대로 설명하지는 않습니다.
물론 사양은 사용자 요구사항보다 덜 자주 변경되므로 무언가를 빌드하는 방식을 변경하기로 한 결정을 뒷받침할 수 있다면 괜찮을 것입니다.
예를 들어 보겠습니다. '가격'이라는 카드 구성요소를 빌드하고 있으며 이 구성요소에 세 개의 요소가 있다고 가정해 보겠습니다. Hayden Pickering은 각 카드를 목록 요소에 넣을 것을 제안합니다. 이렇게 하면 지원 기술 (AT)을 사용하는 사용자가 해당 섹션에 도달했을 때 가격 목록에 항목이 3개 있다고 안내됩니다. 글머리 기호가 없도록 목록을 스타일링하여 원하는 대로 보이게 할 수 있지만, AT 사용자가 유용한 정보를 먼저 얻는 데 도움이 됩니다. 각 항목을 div로 래핑하면 시각적 측면에만 집중하게 되므로 시각장애인 사용자에게 도움이 되지 않습니다. 디자인보다 사람을 먼저 생각하세요.
이 아이디어를 가져와 블로그 페이지에 적용했습니다. 블로그 게시물은 실제로 목록 요소 내에 있습니다. 이렇게 하면 페이지에 진입할 때 사용자가 페이지에 있는 여러 게시물 중 하나에 있음을 알 수 있습니다.
따라서 MDN에서 추천하는 이유를 이해할 때까지는 도움말의 추천을 따를 것입니다.
Alexandra: MDN 문서가 오픈소스이므로 변경사항을 제안하고 업데이트를 진행할 예정인가요?
수이: 솔직히 아직 오픈소스에 기여한 적이 없습니다. 하지만 정부와 협력하는 것보다 이런 종류의 일을 하고 싶습니다.
사양과 구현
Alexandra: 사양에서는 한 가지를 명시하지만 구현 및 기타 외부 문서에서는 다른 것을 제안할 수 있다는 점이 중요한 내용인 것 같습니다. 어떤 사람의 조언을 따라야 할까요?
슈이: 이 문제에 대해 많이 생각합니다. 이 질문에 답할 수 있는 경험이 있는지 잘 모르겠습니다. Google은 항상 미래를 대비하기 위해 노력하고 있습니다. 웹이 변화함에 따라 지속적으로 개선하는 것이 좋습니다. 이렇게 하면 사양이 업데이트될 때 사이트를 개조하지 않아도 됩니다. 선택한 사양이 3년 후에 변경될 가능성은 얼마나 되나요?
지금 우리가 내리는 모든 선택은 웹의 미래가 어떤 모습일지, 사양 작성자가 어떤 방향으로 나아갈지 추측한 결과입니다.
Alexandra: 웹은 끊임없이 변화하므로 한 사람이 모든 답을 알 수는 없습니다. 작성 중에 사양이 변경되었나요?
수이: 문서 개요 모델이 사양에서 삭제되기 전에 도움말을 작성하기 시작했습니다. 이 모델은 중첩의 깊이에 따라 제목 수준이 자동으로 계산되어야 한다고 제안했습니다. 하지만 실제로 구현된 적이 없었고 이로 인해 개발자에게 많은 문제가 발생했습니다. 개발자에게는 직접 제목을 수정하라는 조언이 제공되었습니다.
사양 변경 전에 기사가 게시되었다면 돌아가서 수정했을 것입니다. Smashing Magazine에 실리는 기사니까요. 하지만 내 개인 블로그에 있었다면 어땠을까요? 그렇지 않을 수도 있습니다. 이는 변경되는 사양을 기반으로 빌드된 전체 웹사이트를 업데이트하는 것이 아니라 기사를 업데이트하는 경우에만 해당합니다.
사양이 변경되면 개발자가 즉시 웹사이트를 변경해야 하나요? 물론 아닐 것입니다. 사이트를 구축할 때 최적의 선택을 계산하고 그 선택을 따릅니다. 사양이 변경되므로 사양에 답이 없을 수 있습니다.
접근성 관련 직업
Alexandra: 전 세계 접근성 표준에 대해 얼마나 많은 시간을 생각하시나요? 표준과 법규는 국가마다 다릅니다. 많은 법률을 읽어보셨을 것이고, 일부 법률에서는 반대되는 내용을 요구할 수도 있습니다. 이러한 경우 어떻게 해야 할까요?
수이: 프리랜서 접근성 작업을 위한 비즈니스를 시작하려고 생각 중이야. 글로벌 웹 접근성 채팅 채널에 들어가 시작하는 방법에 관한 팁을 요청했습니다. Adrian Roselli는 연락을 통해 '클라이언트는 법규를 준수할 수 있도록 귀사에 의존할 것이며, 이는 심각한 결과를 초래할 수 있습니다. 서비스를 제공하기 전에 전문 지식을 갖춘 지역을 파악하세요. 자신이 잘 아는 법률을 파악하여 생계를 유지하는 동안 고객에게 막대한 책임이 발생하지 않도록 하세요. 법을 잘 알고 있다고 믿고 있습니다.'
물론 많은 기업이 접근성 지원을 찾는 이유는 단순히 올바른 일이기 때문이 아니라 법적 요구사항이기 때문입니다. 자본주의는 접근성이 구현되는 이유입니다. 결국 중요한 것은 이유가 아니라 제품에 액세스할 수 있는지 여부입니다.
해당 지역의 법률에 따라 고객을 도울 수 있다는 확신이 들 때까지 프리랜서 활동을 중단했습니다. 표준화는 매우 중요하며 WCAG의 노력과 영향은 아무리 강조해도 지나치지 않습니다. 웹 작동 방식에 관한 중앙 프레임워크가 있으면 정부가 동일한 표준을 더 쉽게 사용할 수 있습니다. 하지만 모든 정부가 이러한 표준을 수용하는 것은 아닙니다.
Alexandra: 접근성 여정을 시작하면서 훌륭한 분들로부터 많은 좋은 조언을 받으셨습니다. 이 분야를 직업으로 선택하기 전에 알았으면 좋았을 만한 다른 조언이 있나요?
수이: 내 진로를 바꾸지는 않았겠지만 접근성 작업이 고귀한 만큼 자본주의의 영향을 많이 받는다는 것을 알았으면 좋았을 것 같습니다.
Alexandra: [웃음] 네.
수이: 저는 주니어입니다. 접근성 분야에서 1년의 경험이 있습니다. 특히 저처럼 아프리카에 거주하는 경우 접근성 분야의 일자리가 제한적입니다. 회사는 필요한 법적 요구사항을 충족하기 위해 관리자 한 명을 채용합니다. 하지만 기술을 배우고 쌓을 수 있는 팀에서 일하고 싶습니다.
JavaScript를 배우지 않고도 바로 업무에 투입될 수 있다는 점이 정말 좋았습니다. 규칙만 배우고 팀에서 규칙을 적용하도록 도울 수 있었기 때문입니다. 하지만 대행사의 개발자 직책에는 JavaScript 경험이 필요합니다. 이러한 요구사항을 충족하기 위해 새 도시로 이사하고 JavaScript 부트캠프에 참여했습니다. 접근성 여정을 시작하는 다른 분들은 먼저 개발 기술을 쌓는 데 집중해야 합니다.
솔직히 말해서 아직 JavaScript를 좋아하지 않습니다.
한 가지 작업: 키보드 포커스 추가
Alexandra: 제가 이제 개발자가 아닌 기술 문서 작성자가 된 이유가 JavaScript 때문인가요? 네, 정말 싫어요. 부트캠프에서 좋은 결과를 거두시길 바랍니다.
개발자가 사이트의 접근성을 높이기 위해 해야 하는 일 한 가지는 무엇인가요?
Shuyi: 키보드 포커스 진심으로 부탁드립니다. 트랙패드가 작동하지 않아서 이동 중에는 키보드를 사용하여 웹을 탐색하는데 거의 모든 웹사이트가 끔찍합니다. 키보드 포커스는 장애인에게만 유용한 것이 아닙니다.
접근성 높은 플랫폼을 구축하면 모두에게 도움이 됩니다.
Twitter @shuyiolutimi에서 Shuyi의 작업을 확인하세요.