웹 접근성을 공부하면서 마우스를 사용하지 못하는 지체 장애인 분들을 위해 키보드만으로 웹 조작이 가능하도록 고려해야한다는 것을 알게되었고, 이를 해결해 줄 수 있는 제일 간단한 방법이 tabIndex 속성을 이용하는 것이었습니다.

 

이러한 tabIndex를 이용해 키보드 접근성을 제공하기 위해선 어떻게 사용하면 되는지 학습한 내용을 정리하겠습니다.

 

tabIndex란?

tabIndex는 키보드의 탭 키를 눌렀을 때 포커스의 이동 순서를 임의로 조정할 수 있는 HTML의 속성입니다. 그리고 순서를 부여하는 방식을 tabIndex 값에 양의 정수를 넣어주면 됩니다. 어떠한 값도 넣지 않았다면 사용자와 상호작용(interactive)이 가능한 요소(element)로 키보드 포커스가 잡히게 되어 있습니다. 대표적으로 <input>, <select>, <button> 같은 양식(form) 관련 요소(element)와 <a> 요소입니다. 해당 요소를 마크업 순서에 따라 자연스럽게 이동합니다. 그러므로 마크업이 논리적으로 구현되어 있다면 tabIndex를 사용할 필요는 없는 것입니다. 오히려 잘못된 tabIndex를 사용한다면
스크린 리더 사용자가 웹페이지의 구조를 이해하는 데 어려움을 줄 수 있습니다.

 

tabIndex를 사용하는 경우는?

웹 페이지를 구성하는 과정에서 시각적인 디자인 때문에 사용자와 상호작용이 가능한 요소를 논리적이지 않게 만들어야 하는 경우가 있습니다. 이런 경우에 tabIndex를 이용해 페이지 탐색에 논리적 순서를 부여하여 사용자가 자연스럽게
페이지를 탐색할 수 있도록 해야합니다.

 

tabIndex에서 0과 -1

tabIndex 0

상호작용하지 않는 <div> <span>과 같은 요소에도 키보드 포커스가 잡히게 하고 싶을 경우 tabIndex 값에 0을 설정해 줍니다. 설정해주면 마치 상호작용이 가능한 요소처럼 해당 요소로 포커스가 이동하게 됩니다.

 

tabIndex -1 

0을 지정해주는 것과 반대로 사용자와 상호작용하는 요소에 tabIndex 값 -1을 입력하여 포커스되지 않도록 설정하는 것입니다. 

 

 

위에서도 언급했지만 논리적으로 마크업 순서가 맞는다면 tabIndex를 사용하실 필요 없습니다. 또한 tabIndex 사용보다 마크업 순서를 논리적으로 배치하는 것을 추천한다고 하네요.

 

그리고 tabIndex를 적용해보고, 구글 확장 프로그램 스크린 리더를 설치해 직접 테스트 해보며 원하는 논리 로직에 맞게 잘 적용되었는지 체크해 보는게 좋을 것 같습니다. 

 

스크린 리더 확장 프로그램을 설치한 후 페이지를 실행하여 

직접 tab을 눌러보며 놓치는 요소나 설명이 부족한 요소가 없는지 확인하고 적절하게 tabIndex를 사용해주며 스크린 리더 사용자들이 해당 서비스를 이용할 때 불편함이 없도록 업데이트 할 수 있습니다.

 

예를 간단하게 들자면 온도별 코디를 보여주는 서비스에서 날씨 아이콘이 image 태그이기 때문에 스크린 리더 사용자는 현재 날씨와 온도를 알지 못하고 넘어가고 있었습니다. 각 태그에 tabIndex 0값을 지정해주어 alt로 설명을 더해주는 방식으로 업데이트 했습니다.

 

이상입니다. 글 읽어주셔서 감사합니다.

 

현재 진행 중인 프로젝트를 vercel에 배포한 후 계속 500 에러가 발생했습니다. 임시 데이터로 진행할 때 500에러가 발생하지 않았지만 호출한 데이터를 사용하도록 코드를 변경하면 계속 500 에러가 발생했습니다.

 

500 에러의 경우 서버에서 발생한 것이기 때문에 페이지 콘솔에서는 아무것도 확인할 수 없었습니다. 이 경우 vercel의 로그를 확인해야합니다. 로그를 확인하고 500 에러를 해결하는 과정을 작성할 예정입니다.

 

맨 밑에 결론이 있습니다. 어떻게 해결하면 되는지 궁금하신 분은 바로 결론 봐주시면 됩니당 :)

 

 

1. Details 접속

생각보다 간단합니다. vercel에 배포한 상태에서 github에 push하고 pr을 진행할 때, 아래 사진과 같이
Details를 확인할 수 있습니다.

클릭하여 Deployment 옆에 있는 Logs를 클릭하여 어떤 오류가 발생했는지 확인하고 해결하면 됩니다.

 

 

 

2. 로그 확인을 통한 에러 발생 원인 파악

 

⨯ Error: Could not load the "sharp" module using the linux-x64 runtime

 

이렇게 어디 부분에서 문제가 발생했는지 알 수 있습니다. 필자의 경우는 linux-x64 환경에서 sharp 모듈을 로드할 수 없어 발생한 문제였습니다. 이는 linux-x64 환경에서 모듈을 사용할 수 있도록 

옵션 의존성 설치나 플랫폼을 지정하여 설치해주면 된다고 합니다.

 

 

옵션 의존성 설치

먼저 옵션 의존성 설치를 진행한 후 다시 배포하여 오류가 해결되는지 확인해 보겠습니다.

위 명령어를 입력하여 설치한 후 github에 push 했습니다.

 

해당 오류가 발생했습니다. 사실 이건 이전에도 발생했던 오류입니다. 그 이유는 sharp 라이브러리는 0.33.2 이상 버전부터 vercel 배포 환경에서 오류를 발생시키더라고요. 그렇기에 위에서 옵션 의존성 설치를 진행할 때 버전을 0.33.1 버전으로 설치해줘야합니다. 

 

다시 설치를 진행하고 배포를 진행해보겠습니다.

설치 후 다시 확인해 봤는데 RangeError는 발생하지 않지만 여전히 같은 에러가 발생했습니다.

 

 

플랫폼 지정 설치

설치 후 다시 push 진행했는데도 같은 에러가 발생하네요..ㅠㅠㅠ

 

 

Vercel only: 0.33.0: error Could not load the "sharp" module using the linux-x64 runtime · Issue #3870 · lovell/sharp

Possible bug Is this a possible bug in a feature of sharp, unrelated to installation? Running npm install sharp completes without error. Running node -e "require('sharp')" completes without error. ...

github.com

해결하기 위해 찾아본 결과 sharp 버전 문제인 것 같아서 버전을 한단계 더 낮춰 옵션 의존성 설치를 진행한 후 다시 배포해보겠습니다.

 

똑같이 에러가 발생하여 버전을 0.32.6으로 낮추어 다시 배포해 보겠습니다.

 

한가지 간과한 점이 npm uninstall sharp를 하지 않고 덮어써서 문제가 발생한 것 같습니다. 
uninstall을 진행한 후 0.33.1로 재설치 해보겠습니다.

 

여전히 같은 에러가 발생하네요..ㅠㅠ 0.32.6으로 버전을 낮춰 다시 배포해 보겠습니다.

 

 

결론

 

sharp 0.32.x 버전으로 다운 그레이드 하자

 

드디어 해결했습니다! 생각보다 너무 가벼운(?) 해결방법이라 허무했습니다..ㅠㅠ
AWS Lambda 환경에서 0.32.6 이상의 sharp 라이브러리가 작동하지 않는 것 같습니다. 버전을 0.32.6으로 낮추고 실행하니 500 에러가 더이상 발생하지 않습니다. 좀 더 공부하여 버전을 낮추는 해결 방법이 아닌 최신 라이브러리를 사용하더라도 오류를 해결할 수 있는 방법을 찾아보겠습니다 이상입니다. 긴 글 읽어주셔서 감사합니다.

시맨틱 태그란 무엇일까?

시맨틱(semantic)이라는 것은 '의미의', '의미론적인'이라는 뜻을 까진 형용사입니다.
즉, div 태그에 의미를 부여하여 문서의 가독성을 높이기 위해 만들어진 태그입니다.

HTML5에서 처음 등장 했으며 <header>, <nav>, <article>, <section>, <footer>, <main> 으로 직관적인 문서 설계가 가능합니다.

 

 

시맨틱 태그를 사용해 얻을 수 있는 이점

  • 유지 보수성이 증가합니다. : HTML 문서의 가독성과 유지 보수가 쉬워집니다.
  • 웹 접근성이 높아집니다. : 웹 브라우저가 HTML만 보고도 상단(header), 본문(main), 하단(footer), 사이드(aside) 등 어느 영역인지 쉽게 알 수 있습니다. 이를 통해 시각 장애인들이 사이트를 사용할 때 이용하는 스크린 리더기에서 유용하게 사용될 수 있습니다.
  • SEO 측면에서 유리합니다. : 검색 엔진은 웹페이지의 여러 정보들을 수집해서 검색 키워드에 알맞게 노출시킵니다. 이 때 시맨틱 태그로 작성할 경우 검색 엔진에 노출되기 좋아집니다.

 

시맨틱 태그에 대해 알아봅시다!

다양한 방식으로 구현 될 수 있습니다. 우선 레이아웃 예시들을 보고 각 태그들에 대해 설명하겠습니다.

<예시 1 : main에 article, aside, section을 모두 포함>
<예시 2 : main과 aside를 분리>

main에 포함과 분리 뿐만 아니라

article로 콘텐츠를 분리하고 section을 나누기도 하고,

section으로 콘텐츠를 분리하고 article로 나누기도 하는데

이는 각 태그에 대해 알면 어떻게 사용할지 감을 잡을 수 있습니다. 

 

header

  • hearder는 웹 사이트의 상단에 위치하는 태그이며, 로고나 검색 로그인 등의 글로벌 링크가 위치합니다.

nav

  • nav는 페이지의 특정 콘텐츠나 다른 페이지로 이동할 수 있는 버튼 등을 모아둔 메뉴 영역입니다.
  • 네비게이션의 약자이며, 본문의 위치에 영향을 받지 않고 어디서든지 독립적으로 사용가능합니다,

main

  • 본문 내용을 나타내는 태그이며 IE ( Internet Explorer ) 환경에서는 지원하지 않습니다.
  • 웹 페이지에서 단 한 번만 사용해야 합니다.
  • 내부에서 article과 section을 이용헤 구조적인 웹사이트를 구성하는 것이 좋습니다.

aside

  • 전체 내용과 연관성이 있지만, 주 콘텐츠와 분리되어 직접적인 상관이 없는 부가적인 내용을 담습니다.
  • 주로 사이드바에 적용되며 세로로 따로 배치됩니다.

(저는 main 태그와 분리하는게 더 적절하다고 생각합니다.)

 

article

  • 독립적인 내용을 나타낼 때 사용합니다.
  • 즉, <main>안에 있는 다른 내용들과 전혀 상관없이 독립적으로 고유한 정보를 나타낼때 사용합니다.
  • 일반적으로 제목 태그를 포함시켜 사용합니다.
  • article이나 section을 자식으로 포함해도 문제되지 않습니다.

section

  • 주 내용에서 흐름을 나눠주는 태그입니다. 책에서의 챕터 역할이라고 생각하면 편합니다.
  • 연관있는 내용들을 묶어주고 싶을 때 사용합니다.
  • 일반적으로 제목 태그를 포함시켜 사용합니다.
  • main 안에서 연관있는 내용들을 묶어주기 위해 사용되기도하고,
    article 안에서 연관있는 내용들을 묶어주기 위해 사용되기도 합니다.

※ aeticle과 section

둘은 약간 헷갈릴 수 있는 내용이라고 생각되어 사용 예시를 들어 정리하고자 합니다.

<main>
   <article>
    	독립적인 내용이며 다른 내용과 연관이 없음
    	<secttion>
        	연관 있는 내용들끼리 묶어줌
    	</secttion>
    </article>
    
    <secttion>
    	연관 있는 내용들
        <article></article>
    </secttion>
    
    <secttion>
    	연관있는 내용들
    </secttion>
</main>

위와 같이 

- artcle로 콘텐츠를 나눈 후 section으로 묶어둬도 되고, (그 안에 또 article을 사용하는 것도 가능)

- section으로 관련 내용끼리 분할한 후 article로 나누어도 됩니다. (article 안에서 또 section으로 내용을 나누어줘도 됨)

위의 두개를 모두 합쳐서 사용해도 되지만 ,

헷갈리지 않기 위해선 자신만의 기준을 잘 잡아놓고 나누는 것이 좋을 것 같습니다.

 

figure, figcaption

  • figure는 이미지 영역을 나타내는 태그입니다. img와 figcaption을 자식으로 포함시켜 사용합니다.
  • figcaption은 이미지에 대한 설명을 나타매고 반드시 figure을 부모로 두어야합니다.
  • 여기서 중요한 점은 figcaption 태그의 내용은 alt와는 구별되어야 합니다.
  • 동일한 내용이 들어가면 스크린 리더기는 중복된 내용을 출력할 것이기 때문입니다. 이미지에 대한 설명, 또는 사진과 관련 있는 설명은 figcaption에 포함시키고, alt에는 이미지 자체를 표현할 수 있는 단어나 문장을 포함시키면 됩니다.

footer

  • 최하단에 위치합니다. 저작권, 사업자정보, 전화번호, 주소 등
    웹사이트나 기업의 정보를 표시하는 공간으로 활용합니다.

details, summary

  • details은 사용자가 보거나 숨실 수 있는 추가 세부 정보를 정의하는 태그입니다.
  • 사용자는 버튼을 통해 열고 닫을 수 있습니다.
  • 기본적으로 닫은 상태에 있고 클리하면 내용이 보이며 확장되는 성질을 가집니다.
  • 여기서 summary 태그가 사용되는데 details에서 보이는 부분을 담당합니다.
  • summary 태그는 details태그의 첫번째 하위 항복이어야합니다.

 

스크린 리더 읽힐 때 차이가 나는 태그들도 몇개 알아보고 가면 좋을 것 같습니다.

 

<i> VS <em>

<i> : 이탤릭체를 시각적으로만 사용하고 싶을 때 사용

<em> : 이탤릭체를 강조하고 싶을 때 사용

 

<b> VS <strong>

<b> : 시각적으로만 볼드체를 사용하고 싶을 때

<strong> : 강조하는 볼드테에 사용

 

이상입니다. 읽어주셔서 감사합니당 :)

 

웹 표준이란?

웹 표준은 웹에서 사용되는 기술들의 표준화를 의미합니다.
즉, 웹사이트를 구성할 때 사용하는 HTML, CSS, JavaScript등을 표준화된 방식으로 작성되어야 한다는 것입니다.
이러한 웹표준을 지켜 웹사이트를 만든다면 어떤 브라우저나 기기를 사용하더라도
홈페이지 화면을 동일하게 볼 수 있습니다. 그렇기에 우리는 개발을 할 때 웹 표준을 고려해야 하는 것입니다.

웹 표준을 준수할 경우 얻을 수 있는 이점

  1. 웹 페이지가 모든 브라우저에서 일관적으로 표시되며, 모든 사용자에게 동일한 사용자 경험을 제공할 수 있습니다.
  2. 검색 엔진 최적화에 유리합니다.
  3. 유지 보수 밒 확작성이 좋아지고 보장됩니다.
  4. 웹 접근성 또한 향상됩니다.

 

웹 표준을 준수하는 방법!

  1. DOCTYPE 선언 :
    웹 페이지의 최상단에 DOCTYPE을 선언하여  웹 페이지가 어떤 버전의 HTML, XHTML을 사용하는지 명시합니다.

  2. 시맨틱 태그 사용 :
    <header>,<nav>,<section>,<footer> 등 웹 페이지의 구조를 명확하게 표한하는 시맨틱 태그를 사용합니다.

  3. css 스타일 시트 사용 :
    css 스타일 시트를 사용해 디자인과 레이아웃을 분리하고 웹 페이지의 내용과 디자인을 분리하여 유지보수와 확장성을 높일 수 있습니다.

  4. 웹 접근성 고려 :
    모든 사용자가 쉽게 접근할 수 있도록 웹을 제작하여야 한다. 예를 들어 시각 장애인이 스크린 리더를 사용하여 웹 페이지를 읽을 수 있도록 alt 속성을 사용한다거나 키보드만으로 모든 기능을 사용할 수 있도록 tabindex 속성을 사용하는 등이 있습니다.

여기서 웹 접근성이란 무엇인지 알아봅시다.

 


 

웹 접근성

 

장애를 가진 사람들도 신체적 환경적 조건에 관계 없이 인터넷을 통해 정보에 접근하고 이용할 수 있도록 하는 것을 말합니다. 이를 통해 인터넷을 인종, 성별, 연령, 장애 유무와 상관 없이 모두가 이용할 수 있는 공간으로 만듭니다.


예를 들자면, 위에서 언급했듯이 시각 장애인이 웹을 사용하기 위해 이용하는 스크린 리더를 고려해 이미지만 쓰는 것이 아닌 이미지를 설명하는 alt를 사용하는 것이 있습니다.



웹 접근성을 준수하기 방법

  1. 시각적 요소 처리 :
    시각 장애인은 이미지, 비디오, 그래픽, 등을 시각적 요소를 인식할 수 없다는 것을 인지해야합니다.
    따라서 대체 텍스트, 색상 대비, 텍스트 크기 등을 고려해 시각적 요소를 처리해야합니다.

  2. 청각적 요소 처리 :
    청각 장애인오디오 콘텐츠를 이해할 수 없습니다.
    때문에 자막, 수화, 오디오 설명 등을 제공하여 청각적 요소를 처리해야합니다.

  3. 키보드 접근성 :
    지체 장애인은 마우스를 사용하지 못하는 경우가 많습니다.
    그렇기에 키보드만으로 웹사이트를 이용할 수 있도록 고려해야합니다.

  4. 웹 접근성 검사 :
    WCAG 준수 여부를 검사하여 웹 접근성을 확보해 봅시다.

 

WCAG란?

웹 콘텐츠 접근성 지침(WCAG)이란 웹 접근성을 확보하기 위한 국제 표준입니다.
4가지 원칙, 13가지 지침, 78가지 성공 기능으로 구성되어 있습니다.

 


 

1. 인식의 용이성

정보와 사용자 인터페이스 요소는 그들이 인지할 수 있도록 사용자에게 표시되어야 한다.
다수의 감각을 사용해 어떤 방식으로든 인지할 수 있어야한다.

 

a. 텍스트가 아닌 콘텐츠에 대체 텍스트를 제공해야한다. (인쇄, 점자, 음성, 기호 등)

 

b. 정보와 구조의 손실 없이 콘텐츠를 표현할 수 있어야 한다.(콘텐츠에 대한 간단한 소개)

 

c. 전경(선택된 정보)과 배경(그 이외의 정보)을 분리하는 등 사용자가 콘텐츠를 보다 쉽게 보고 들을 수 있도록 한다.


 

2. 운용의 용이성 

사용자 인터페이스 요소와 탐색은 운용 가능해야한다. 쉽게 말하면 모든 사용자가 UI 요소들을 컨트롤 할 수 있어야한다. (마우스 → 키보드 || 음성 명령 등)

 

a. 키보드로 모든 기능을 사용할 수 있어야한다.

 

b. 읽기 및 콘텐츠를 사용하는 사용자에게 충분한 시간을 제공해야한다.

 

c. 사용자가 콘텐츠를 탐색하는 방법그들이 어디에 위치하고 있는지를 알 수 있는 방법제공해야한다.


 

3. 이해의 용이성 

정보와 사용자 인터페이스 운용은 이해할 수 있어야한다.

 

a. 텍스트 콘텐츠를 판독하고 이해할 수 있도록 만들어야 한다.

 

b. 웹 페이지의 탑재와 운용을 예측 가능한 방법으로 제작해야한다.

 

c. 사용자의 실수을 방지하고 수정할 수 있도록 도와야한다


 

4. 내구성

콘텐츠는 각기 다른 브라우저에서 현재와 미래에 모두 동작할 수 있도록 웹 표준을 준수해 개발하여야 한다. 즉 호환성을 최대로 높여야한다.


 

위의 내용은 WCAG 2.0 기준입니다.

현재는 WCAG 2.1을 채택해 사용하고 있다고 합니다.

먼저 WCAG 2.0을 충족하고 단계적으로 2.1을 적용할 예정입니다.

 

WCAG 2.1

  • 시각 (Visual)
  • 청각 (Auditory)
  • 지체 (Physical)
  • 음성 (Speech)
  • 인지 (Cognitive): WCAG 2.1 추가 항목
  • 언어 (Language)
  • 학습 (learning): WCAG 2.1 추가 항목
  • 신경 (Neurological)

참고 블로그

 

🌐 웹 표준 & 웹 접근성 이란?

웹 표준 (Web Standards) 웹 표준은 웹에서 사용되는 기술들의 표준화를 의미한다. 즉, 웹 사이트를 구성하는 HTML, CSS, JavaScript 등의 언어들이 표준화된 방식으로 작성되어야 한다는 것이다. 쉽게 말

inpa.tistory.com

 

 

[HTML] 웹 콘텐츠 접근성 가이드라인 WCAG 2.1

웹 콘텐츠 접근성 가이드라인(이하 WCAG)은 Web Content Accessibility Guidelined의 약자로, 어떠한 장애유형에 영향을 받지 않고 모든 사람이 웹 콘텐츠에 보다 쉽게 접근할 수 있게 만들기 위해 발표된 W3C

velog.io

 

 

웹 컨텐츠 접근성 지침 이해하기 - 접근성 | MDN

이 문서에서는 W3C 웹 컨텐츠 접근성 지침 2.0 또는 2.1(이 글에서는 WCAG)에 설명된 권장 사항들을 준수하기 위한 단계들을 이해하는 데에 도움이 되는 간략한 설명을 제공합니다.

developer.mozilla.org

 

+ Recent posts