장애인 버튼에 대해 이야기합시다. 구체적으로, 우리가 왜 그것들을 사용하는지, 그리고 버튼을 비활성화 한 것으로 표시하기 위해 HTML (예 :
장애인 버튼이 많은 의미가있는 사용 사례가 많이 있으며, 우리는 그 이유를 잠시만 갈 수 있습니다. 그러나이 기사를 통해 우리는 쇼핑 카트에 여러 티켓을 추가 할 수있는 양식을 살펴볼 것입니다.
"장바구니 추가"버튼을 비활성화하는 명확한 상황이 있기 때문에 이것은 좋은 기준 예입니다. 카트에 추가 할 티켓이 없을 때.
사람들이 무효 또는 사용할 수없는 조치를 취하는 것을 방지하는 것은 장애인 버튼에 도달 할 수있는 가장 일반적인 이유입니다. 아래 데모에서는 카트에 추가되는 티켓 수가 0보다 큰 경우에만 티켓을 추가 할 수 있습니다. 시도해보십시오.
이 데모에서 코드 설명을 건너 뛰고 중요한 내용 인 "장바구니 추가"버튼에 관심을 집중시킬 수 있습니다.
카트에 추가하십시오 버튼>
이 버튼은 비활성화 된 속성으로 비활성화됩니다. (이것은 부울 속성이라는 점에 유의하십시오. 즉, 장애인 또는 비활성화 된 것으로 쓸 수 있음을 의미합니다. = "비활성화".)
모든 것이 괜찮아 보인다… 그래서 무엇이 잘못 되었습니까?
솔직히 말해서, 나는 여기에서 기사를 끝내고 장애인 버튼이 빨기 때문에 사용하지 말고 대신 더 나은 패턴을 사용하도록 요청할 수 있습니다. 그러나 현실적으로합시다 : 때로는 버튼을 비활성화하는 것이 가장 의미가있는 솔루션입니다.
이 데모 목적을 위해, 우리는“카트에 추가”버튼을 비활성화하는 것이 최상의 솔루션 인 척합니다 ( 스포일러 경고 : 그렇지 않음). 우리는 여전히 그것이 어떻게 작동하는지 배우고 그 과정에서 유용성을 향상시키는 데 사용될 수 있습니다.
장애인 버튼을 사용할 수 있다는 의미를 명확히하고 싶습니다. 버튼이 비활성화되면 사용할 수 없어야한다고 생각할 수 있습니다. 캐치는 무엇입니까?
나와 함께 견디십시오.
웹에는 페이지와 상호 작용하는 여러 가지 방법이 있습니다. 마우스를 사용하는 것이 가장 일반적이지만, 모터 장애로 인해 키보드를 사용하여 탐색하는 시력이있는 사람들과 같은 다른 사람들이 있습니다.
탭 키 만 사용하여 위의 데모를 탐색하여 앞으로 나아가고 탭 전환을 뒤로 이동하십시오. 비활성화 버튼이 건너 뛸 방법을 알 수 있습니다. 초점은 티켓 입력에서 "더미 용어"링크로 직접 이동합니다.
잠시 잠시 멈추고 우리가 처음에 버튼을 비활성화하는 것과 실제로 달성 한 것과 비교할 수있는 이유를 요약합시다.
"상호 작용"을 "클릭"과 연관시키는 것이 일반적이지만 두 가지 다른 개념입니다. 예, C Lick 은 상호 작용의 한 유형이지만 호버와 초점과 같은 다른 것 중 하나 일뿐입니다.
다시 말해서…
우리의 목표는 클릭을 방지하는 것입니다. 그러나 비활성화 된 사용을 통해 클릭뿐만 아니라 초점을 방지하고 있습니다. 즉, 우리는 좋은 해를 입을 수 있습니다. 물론,이 행동은 무해 해 보일 수 있지만 혼란을 유발합니다. 인지 장애가있는 사람들은 버튼에 집중할 수없는 이유를 이해하기 위해 고군분투 할 수 있습니다.
다음 데모에서는 레이아웃을 약간 조정했습니다. 마우스를 사용하고 제출 버튼 위로 마우스를 사용하는 경우 버튼이 비활성화 된 이유를 설명하는 툴팁이 표시됩니다. 그거 대단해!
그러나 키보드 만 사용하는 경우 버튼을 비활성화하여 초점을 맞출 수 없기 때문에 해당 툴팁을 볼 방법이 없습니다. 터치 장치에서도 마찬가지입니다. 아야!
코드 설명을 다시 한번 건너 뛸 수 있습니다. Sarah Higley의 Haydon Pickering과 "WCAG 2.1 시점의 툴팁"으로 "포괄적 인 도구"를 읽어 도구 팁 패턴을 완전히 이해하는 것이 좋습니다.
의 비활성화 속성은 필요한 것보다 더 많은 일을하고 있습니다. 이것은 기본 HTML 속성이 좋은 것보다 더 해를 끼칠 수있는 곳에 대해 알고있는 몇 가지 사례 중 하나입니다. ARIA 속성을 사용하면 더 나은 작업을 수행하여 화면 리더에게 버튼을 해석하는 방법을 지시 할 수 있지만 더 많은 사람들과 사용 사례에 대한 포괄적 인 경험을 일관되게 만들 수 있습니다.
비활성화 된 속성은 ARI-DISIBLED = "TRUE"와 관련이 있습니다. 키보드 만 사용하여 다음 데모를 다시 시도하십시오. 버튼이 표시되지 않더라도 장애인이지만 포커스로 여전히 액세스 할 수 있고 툴팁을 트리거 하는 방법에 주목하십시오!
멋져요? 큰 개선을위한 그런 작은 조정!
그러나 우리는 아직 끝나지 않았습니다. 여기서주의 사항은 여전히 JavaScript를 사용하여 클릭을 프로그래밍 방식으로 방지해야한다는 것입니다.
elform.addeventListener ( '제출', function (event) {
event.preventDefault (); / * 기본 양식 제출 방지 */
const isdisabled = elbuttonsubmit.getAttribute ( 'aria disabled') === 'true';
if (isdisabled || issubmitting) {
// 티켓이 추가되는 것을 방지하기 위해 일찍 돌아옵니다.
반품;
}
issubmitting = true;
// ... 카트에 추가 할 코드 ...
issubmitting = false;
})더블 클릭이 양식을 두 번 제출하는 것을 방지하는 방법 으로이 패턴에 익숙 할 수 있습니다. 그 이유 때문에 장애인 속성을 사용하고 있다면 양식이 제출되는 동안 키보드 초점의 일시적 손실을 유발하기 때문에 그렇게하지 않기를 원합니다.
Aria Disabled가 기본적으로 클릭을 방해하지 않으면 사용의 요점은 무엇입니까? 이에 대답하려면 두 속성의 차이점을 이해해야합니다.
둘 사이의 유일한 겹침은 의미론입니다. 두 속성 모두 버튼이 실제로 비활성화되었다고 발표 할 것입니다.
장애가있는 속성과 달리 Aria-disabled는 의미론에 관한 것입니다. ARIA 속성은 기본적으로 응용 프로그램 동작이나 스타일을 변경하지 않습니다. 그들의 유일한 목적은 보조 기술 (예 : 스크린 리더)이 더 의미 있고 강력한 방식으로 페이지 컨텐츠를 발표하도록 돕는 것입니다.
지금까지 우리는 두 가지 유형의 사람들, 클릭 한 사람들과 탭을하는 사람들에 대해 이야기했습니다. 이제 다른 유형에 대해 이야기 해 봅시다 : 시각 장애가있는 사람들 (예 : 실명, 낮은 비전)이 스크린 리더를 사용하여 웹을 탐색하는 사람들.
스크린 리더를 사용하는 사람들은 종종 탭 키를 사용하여 양식 필드를 탐색하는 것을 선호합니다. 이제 MacOS의 음성이 장애인 버튼을 완전히 건너 뛰는 방법을보십시오.
다시 한번, 이것은 매우 최소한의 형태입니다. 더 긴 경우, 제출 버튼을 찾는 버튼을 바로 찾는 것은 성가신 일 수 있습니다. 제출 버튼이 숨겨져 있고 양식을 완전히 작성할 때만 볼 수있는 양식을 상상해보십시오. 장애인 속성이 사용될 때 어떤 사람들이 느끼는 것입니다.
다행스럽게도 장애가있는 버튼은 화면 리더가 완전히 도달 할 수 없습니다. 각 요소를 개별적으로 하나씩 탐색 할 수 있으며 결국 버튼을 찾을 수 있습니다.
가능하지만 이것은 성가신 경험입니다. 반면, ARIA DISIBLED를 사용하면 스크린 리더는 버튼을 정상적으로 집중시키고 상태를 올바르게 발표합니다. 발표는 스크린 리더 사이에 약간 다릅니다. 예를 들어, NVDA와 JWAS는“버튼, 사용할 수 없음”이라고 말하지만 Voiceover는“버튼, 어두워졌습니다”라고 말합니다.
방금 사용한 도구를 기반으로 두 속성 모두 다른 사용자 경험을 어떻게 생성하는지 설명했습니다.
따라서 두 속성 사이의 주요 차이점은 다음과 같습니다.
이것은 접근성과 유용성의 미묘한 차이를 인정하는 것이 중요한 경우입니다. 접근성은 누군가가 무언가를 사용할 수있는 척도입니다. 유용성은 무언가를 사용하는 것이 얼마나 쉬운 지에 대한 척도입니다.
이를 감안할 때, 비활성화 할 수 있습니까? 예 . 유용성이 좋습니까? 나는 그렇게 생각하지 않습니다 .
티켓 양식 예제에 대한 진정한 포괄적 솔루션을 보여주지 않고이 기사를 마친다면 나 자신에게 기분이 좋지 않을 것입니다. 가능할 때마다 장애인 버튼을 사용하지 마십시오 . 사람들이 언제든지 클릭하고 필요한 경우 오류 메시지를 피드백으로 표시하도록하십시오. 이 접근법은 또한 다른 문제를 해결합니다.
솔직히 말해서, 장애인 속성이 접근성 문제로 정확히 보이지 않습니다. 저와 관련된 것은 사용성 문제입니다. 장애가있는 속성을 Aria와 비교하여 교체하면 누군가의 경험을 훨씬 더 즐겁게 만들 수 있습니다.
이것은 웹 접근성에 대한 나의 여정에 대한 한 걸음 더 나아가는 것입니다. 수년에 걸쳐 접근성이 웹 표준을 준수하는 것 이상의 것이라는 것을 알게되었습니다. 사용자 경험을 다루는 것은 까다 롭고 대부분의 상황에서는 솔루션에 접근하는 방법에 트레이드 오프와 타협이 필요합니다. 완벽한 접근성을위한은 총알은 없습니다.
웹 제작자로서 우리의 의무는 이용 가능한 다양한 솔루션을 찾고 이해하는 것입니다. 그래야만 최선의 선택을 할 수 있습니다. 문제가 존재하지 않는 척하는 것은 의미가 없습니다.
하루가 끝나면 웹을보다 포괄적 인 장소로 만들지 못하게하는 것은 없습니다.
아직도 거기? 이 데모에 대한 마지막 두 가지를 언급하겠습니다.
데모에서는 콘텐츠의 두 부분이 동적으로 변경되었습니다 : 양식 제출 버튼과 성공 확인 ( "x] 티켓 추가!").
그러나 이러한 변화는 스크린 리더를 사용하는 시력 장애가있는 사람들에게는 현실이 아닙니다. 이를 해결하려면 해당 메시지를 살아있는 지역으로 바꿔야합니다. 이를 통해 보조 기술은 변경 사항을 듣고 업데이트 된 메시지가 발생할 때 발표 할 수 있습니다.
데모에는 로딩 메시지가 포함 된 을 숨기는 .SR 전용 클래스가 있지만 스크린 리더가 발표 할 수 있습니다. 이 경우 aria-live = "Assertive"는
<button type="제출" aria disabled>
카트에 추가하십시오
<span aria-live="Assertive">
</span>
버튼>
<p aria-live="Assertive">
</p></button>요소가 아직 메시지를 보유하지 않더라도 Aria-Live 속성은 처음부터 DOM에 존재해야합니다. 그렇지 않으면 보조 기술이 제대로 작동하지 않을 수 있습니다.
이 작은 Aria-live 속성과 그 큰 일에 대해 더 많은 것을 말해 줄 것이 더 많습니다. Gotchas도 있습니다. 예를 들어, 잘못 적용되면 속성이 좋은 것보다 더 해를 끼칠 수 있습니다. IRE Aderinokun과 Adrian Roselli의“Aria-Live 사용”을 읽는 것은 그것이 어떻게 작동하는지와 사용 방법을 더 잘 이해하기 위해 읽을 가치가 있습니다.
이것은 웹에서 본 대안 (및 잘못된) 구현입니다. 이것은 포인터 이벤트를 사용합니다 : 없음; CSS에서 클릭을 방지합니다 (HTML 속성없이). 제발, 이것을하지 마십시오. 이유를 희망적으로 보여줄 못생긴 펜이 있습니다. 나는 반복한다, 이것을 하지 마십시오 .
CSS는 실제로 마우스 클릭을 방지하지만 초점과 키보드 탐색을 방해하지 않으므로 예상치 못한 결과 또는 더 나쁜 버그로 이어질 수 있습니다.
다시 말해,이 CSS 규칙을 클릭을 방지하기위한 전략으로 사용하는 것은 무의미합니다 (얻을 수 있습니까?). ;)
위 내용은 비활성화 버튼을 더 포괄적입니다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
