Hỗ trợ tiếp cận dành cho nhà phát triển web

Việc cải thiện khả năng tiếp cận giúp trang web của bạn trở nên dễ sử dụng hơn cho mọi người.

Điều quan trọng là phải xây dựng các trang web dành cho tất cả mọi người và dễ tiếp cận. Có ít nhất 6 khía cạnh chính của tình trạng khuyết tật mà bạn có thể tối ưu hoá: hình ảnh, nghe, tính di động, nhận thức, lời nói và thần kinh. Nhiều công cụ và tài nguyên có thể giúp bạn ở đây, ngay cả khi bạn hoàn toàn mới về khả năng truy cập web.

Hơn một tỷ người sống với một dạng khuyết tật nào đó.

Để có thể truy cập, các trang web cần hoạt động trên nhiều thiết bị có kích thước màn hình khác nhau và các kiểu đầu vào khác nhau, chẳng hạn như trình đọc màn hình. Hơn nữa, trang web phải được nhóm người dùng rộng nhất có thể sử dụng, kể cả những người khuyết tật.

Sau đây là một số dạng khuyết tật mà người dùng của bạn có thể gặp phải:

Các vấn đề về thị giác bao gồm từ không có khả năng phân biệt màu sắc cho đến không có thị lực.

• Đảm bảo nội dung văn bản đáp ứng yêu cầu tối thiểu ngưỡng tỷ lệ tương phản.
• Tránh truyền đạt thông tin chỉ sử dụng màu sắc và đảm bảo rằng tất cả văn bản resizable.
• Đảm bảo tất cả thành phần giao diện người dùng đều có thể sử dụng được bằng công nghệ hỗ trợ chẳng hạn như trình đọc màn hình, kính lúp và màn hình chữ nổi. Việc này đảm bảo các thành phần giao diện người dùng được đánh dấu sao cho API hỗ trợ tiếp cận có thể xác định theo phương thức lập trình vai trò, trạng thái, giá trị và tiêu đề của bất kỳ phần tử nào.

Bản thân tôi sống có thị lực kém và tôi thường thấy mình phóng to vào các trang web, Công cụ cho nhà phát triển và thiết bị đầu cuối. Mặc dù việc hỗ trợ thu phóng hầu như không bao giờ là điều mà các nhà phát triển quan tâm hàng đầu danh sách việc cần làm, thì nó có thể tạo ra một thế giới khác biệt đối với những người dùng như tôi.

Vấn đề về thính giác cho thấy người dùng có thể gặp vấn đề về việc nghe thấy âm thanh phát ra từ một trang.

• Cung cấp văn bản thay thế cho tất cả nội dung không hoàn toàn là văn bản.
• Kiểm thử để đảm bảo các thành phần giao diện người dùng vẫn hoạt động tốt không có âm thanh.

Các vấn đề về khả năng vận động có thể bao gồm việc không thể sử dụng chuột, bàn phím hoặc màn hình cảm ứng.

• Tạo nội dung của các thành phần giao diện người dùng có thể sử dụng chức năng từ bàn phím cho mọi thao tác mà người dùng thường dùng chuột.
• Đảm bảo các trang được đánh dấu chính xác cho công nghệ hỗ trợ—bao gồm trình đọc màn hình, phần mềm điều khiển bằng giọng nói và công tắc vật lý có xu hướng sử dụng cùng các API.

Các vấn đề về nhận thức có nghĩa là người dùng có thể cần đến công nghệ hỗ trợ để hỗ trợ họ đọc văn bản, do đó, bạn phải đảm bảo có được lựa chọn thay thế văn bản.

• Hãy lưu ý khi sử dụng ảnh động. Tránh dùng video và ảnh động lặp lại hoặc flash có thể gây ra sự cố cho một số người dùng.

  prefers-reduced-motion Truy vấn phương tiện CSS cho phép bạn giới hạn ảnh động và tự động phát video cho người dùng muốn giảm chuyển động:

  /*
  If the user expresses a preference for reduced motion, don't use animations on buttons.
  */
  @media (prefers-reduced-motion: reduce) {
    button {
      animation: none;
    }
  }
  

• Tránh những hoạt động tương tác dựa trên thời gian.

Có vẻ như có nhiều căn cứ cần giải quyết, nhưng chúng ta sẽ xem xét quy trình đánh giá sau đó cải thiện khả năng hỗ trợ tiếp cận của các thành phần giao diện người dùng.

Để hỗ trợ thêm về hình ảnh, nhóm hỗ trợ tiếp cận của GOV.UK đã tạo một loạt áp phích kỹ thuật số về những điều nên và không nên làm khi hỗ trợ tiếp cận, mà bạn có thể dùng để chia sẻ các phương pháp hay nhất với nhóm của mình.

Đo lường khả năng tiếp cận của thành phần giao diện người dùng

Khi kiểm tra khả năng truy cập vào các thành phần giao diện người dùng của trang, hãy tự hỏi:

• Bạn có thể chỉ sử dụng thành phần giao diện người dùng với bàn phím không?

  Thành phần này có quản lý tiêu điểm và tránh bẫy lấy nét không? Ứng dụng có thể phản hồi các sự kiện bàn phím thích hợp không?

• Bạn có thể sử dụng thành phần giao diện người dùng với trình đọc màn hình không?

  Bạn đã cung cấp văn bản thay thế cho bất kỳ thông tin nào được trình bày dưới dạng hình ảnh chưa? Bạn đã thêm thông tin ngữ nghĩa bằng ARIA chưa?

• Thành phần giao diện người dùng có thể hoạt động mà không có âm thanh không?

  Tắt loa và xem qua các trường hợp sử dụng của bạn.

• Thành phần giao diện người dùng có thể hoạt động khi không có màu không?

  Đảm bảo thành phần giao diện người dùng của bạn có thể được những người không thấy được màu sắc sử dụng. Một công cụ hữu ích giúp mô phỏng người bị mù màu là một tiện ích của Chrome có tên là Mù màu. (Thử tất cả bốn hình thức mô phỏng mù màu có sẵn.) Bạn cũng có thể quan tâm đến Daltonize , cũng hữu ích tương tự.

• Thành phần giao diện người dùng có thể hoạt động khi bật chế độ tương phản cao không?

  Tất cả các hệ điều hành hiện đại đều hỗ trợ chế độ tương phản cao. Độ tương phản cao là một tiện ích của Chrome có thể trợ giúp bạn ở đây.

Các thành phần điều khiển được chuẩn hoá (chẳng hạn như <button> và <select>) có tính năng hỗ trợ tiếp cận được tích hợp vào trình duyệt. Bạn có thể lấy các tệp này làm tâm điểm bằng khoá Tab; chúng phản hồi các sự kiện trên bàn phím (như Enter, Space và các phím mũi tên); và chúng có vai trò, trạng thái và thuộc tính về ngữ nghĩa mà các công cụ hỗ trợ tiếp cận sử dụng. Kiểu mặc định của dịch vụ cũng phải đáp ứng các yêu cầu hỗ trợ tiếp cận được nêu.

Các thành phần giao diện người dùng tuỳ chỉnh (ngoại trừ các thành phần mở rộng tiêu chuẩn các phần tử như <button>) không có tính năng tích hợp sẵn nào, bao gồm khả năng tiếp cận, nên bạn cần cung cấp thông tin này. Một nơi phù hợp để bắt đầu khi Việc triển khai khả năng hỗ trợ tiếp cận là so sánh thành phần của bạn với một tiêu chuẩn tương tự phần tử (hoặc kết hợp một số phần tử tiêu chuẩn, tùy thuộc vào mức độ phức tạp thành phần của bạn).

Hầu hết các công cụ cho nhà phát triển trình duyệt đều hỗ trợ việc kiểm tra cây hỗ trợ tiếp cận của một trang. Trong Công cụ của Chrome cho nhà phát triển, tính năng này có trong thẻ Hỗ trợ tiếp cận trong bảng điều khiển Phần tử.

Firefox cũng có bảng điều khiển Accessibility (Hỗ trợ tiếp cận).

Safari hiển thị thông tin hỗ trợ tiếp cận trong thẻ Nút của bảng điều khiển Phần tử.

Sau đây là danh sách các câu hỏi bạn có thể tự đặt ra khi cố gắng làm cho các thành phần giao diện người dùng dễ tiếp cận hơn.

Cải thiện tiêu điểm bàn phím

Tốt nhất là bạn nên đảm bảo rằng tất cả chức năng trong thành phần giao diện người dùng đều truy cập được bằng bàn phím. Khi thiết kế trải nghiệm người dùng, hãy nghĩ đến cách bạn sẽ sử dụng phần tử của mình chỉ với bàn phím và tìm ra một loạt các tương tác bàn phím nhất quán.

Trước tiên, hãy đảm bảo rằng bạn có mục tiêu lấy tiêu điểm hợp lý cho mỗi thành phần. Ví dụ: một thành phần phức tạp như trình đơn có thể là mục tiêu trọng tâm trong một nhưng sau đó sẽ quản lý tiêu điểm bên trong chính nó để mục trong trình đơn hoạt động luôn là tiêu điểm.

Sử dụng tabindex

Bạn có thể thêm tiêu điểm bàn phím cho các thành phần và thành phần giao diện người dùng bằng tabindex . Người dùng chỉ sử dụng bàn phím và công nghệ hỗ trợ cần có thể đặt bàn phím tập trung vào các phần tử để tương tác với chúng.

Các phần tử tương tác tích hợp sẵn (như <button>) hoàn toàn có thể làm tâm điểm, vì vậy chúng không cần thuộc tính tabindex trừ phi bạn cần thay đổi vị trí của chúng trong thứ tự nhấn phím tab.

Có ba loại giá trị tabindex:

• tabindex="0" là phần tử phổ biến nhất và đặt phần tử này vào thẻ tự nhiên đơn đặt hàng (được xác định theo thứ tự DOM).
• Giá trị tabindex bằng -1 khiến phần tử này được lập trình có thể làm tâm điểm nhưng không theo thứ tự thẻ.
• Giá trị tabindex lớn hơn 0 sẽ đặt phần tử theo thứ tự thẻ thủ công. Tất cả phần tử trong trang có giá trị tabindex dương đều được truy cập trong thứ tự bằng số, trước các phần tử trong thứ tự thẻ tự nhiên.

Xem một số trường hợp sử dụng cho tabindex trong bài viết Sử dụng chỉ mục thẻ.

Đảm bảo tiêu điểm luôn hiển thị, cho dù bằng cách sử dụng vòng lấy nét mặc định hoặc bằng cách áp dụng kiểu lấy nét tuỳ chỉnh rõ ràng. Nhớ đừng mắc bẫy người dùng bàn phím – họ sẽ có thể di chuyển tiêu điểm ra khỏi một phần tử chỉ bằng bàn phím.

Sử dụng tính năng tự động lấy nét

Thuộc tính tự động lấy nét HTML cho phép tác giả chỉ định rằng một phần tử sẽ tự động lấy tiêu điểm khi trang được tải. autofocus đã được hỗ trợ trên tất cả các chế độ kiểm soát biểu mẫu web, bao gồm các nút. Cách tự động lấy nét cho các phần tử trong thành phần giao diện người dùng tuỳ chỉnh của riêng bạn: gọi phương thức focus() được hỗ trợ trên tất cả các phần tử HTML có thể lấy tiêu điểm (ví dụ: document.querySelector('myButton').focus()).

Thêm hoạt động tương tác với bàn phím

Sau khi thành phần giao diện người dùng có thể làm tâm điểm, hãy tạo một câu chuyện tương tác thú vị với bàn phím khi một thành phần được lấy làm tâm điểm bằng cách xử lý các sự kiện bàn phím thích hợp. Ví dụ: cho phép người dùng sử dụng các phím mũi tên để chọn các lựa chọn trong trình đơn và Space hoặc Enter để kích hoạt các nút. Hướng dẫn về mẫu thiết kế của ARIA sẽ cung cấp một số hướng dẫn tại đây.

Cuối cùng, hãy đảm bảo rằng các phím tắt của bạn có thể tìm thấy được. Một phương pháp phổ biến là tạo chú thích cho phím tắt (văn bản trên màn hình) để thông báo cho người dùng rằng các lối tắt đó tồn tại. Ví dụ: "Nhấn ? cho bàn phím lối tắt". Ngoài ra, bạn có thể sử dụng gợi ý, chẳng hạn như chú giải công cụ, để thông báo cho người dùng về một lối tắt.

Tầm quan trọng của việc quản lý tiêu điểm là việc vô cùng quan trọng. Một ví dụ quan trọng là ngăn điều hướng. Nếu bạn thêm thành phần giao diện người dùng vào trang, bạn cần hướng tiêu điểm vào một phần tử bên trong nó; nếu không, người dùng có thể phải di chuyển qua toàn bộ trang để truy cập vào trang đó. Đây có thể là một trải nghiệm khó chịu, vì vậy, hãy nhớ kiểm tra tiêu điểm cho tất cả các thành phần điều hướng bằng bàn phím trên trang của bạn.

// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

Đảm bảo sử dụng thành công trình đọc màn hình

Khoảng 1% đến 2% số người sử dụng trình đọc màn hình. Bạn có thể hiểu tất cả các thông tin và tương tác với thành phần đó bằng trình đọc màn hình và bàn phím một mình?

Các câu hỏi sau sẽ giúp bạn giải quyết vấn đề về khả năng hỗ trợ tiếp cận của trình đọc màn hình.

Có phải tất cả các thành phần và hình ảnh đều có văn bản thay thế phù hợp không?

Bất cứ thông tin nào về tên hoặc mục đích của một thành phần tương tác được truyền tải một cách trực quan, cung cấp một phiên bản văn bản dễ tiếp cận.

Ví dụ: nếu thành phần giao diện người dùng <fancy-menu> chỉ hiển thị biểu tượng bánh răng để cho biết đó là một trình đơn cài đặt, hệ thống cần một văn bản thay thế dễ tiếp cận, chẳng hạn như "cài đặt" truyền tải cùng một thông tin. Tuỳ thuộc vào bối cảnh, bạn có thể cung cấp văn bản thay thế bằng cách sử dụng thuộc tính alt, thuộc tính aria-label, thuộc tính aria-labelledby hoặc văn bản thuần tuý trong DOM tối. Bạn có thể tìm thấy các mẹo kỹ thuật chung trong phần Tham khảo nhanh về WebAIM.

Mọi thành phần giao diện người dùng hiển thị hình ảnh đều phải cung cấp một cơ chế để cung cấp văn bản thay thế cho hình ảnh đó, tương tự như thuộc tính alt.

Các thành phần của bạn có cung cấp thông tin ngữ nghĩa không?

Công nghệ hỗ trợ truyền tải thông tin ngữ nghĩa được biểu thị cho người dùng mà bạn nhìn thấy kèm theo chỉ dẫn trực quan, chẳng hạn như định dạng, kiểu con trỏ hoặc vị trí. Các phần tử được chuẩn hoá có thông tin ngữ nghĩa này được trình duyệt tích hợp sẵn, Tuy nhiên, đối với các thành phần tuỳ chỉnh, bạn cần sử dụng ARIA để thêm thông tin.

Nói chung, mọi thành phần nghe sự kiện nhấp chuột hoặc di chuột cần có một số loại trình nghe sự kiện bàn phím và vai trò ARIA, có thể là Các trạng thái và thuộc tính của ARIA.

Ví dụ: một thành phần giao diện người dùng <fancy-slider> tuỳ chỉnh có thể đóng vai trò thanh trượt ARIA, Tệp này có một số thuộc tính ARIA có liên quan: aria-valuenow, aria-valuemin và aria-valuemax. Bằng cách liên kết các thuộc tính này với các thuộc tính có liên quan trên thành phần tuỳ chỉnh, bạn có thể cho phép người dùng công nghệ hỗ trợ tương tác với phần tử đó, thay đổi giá trị và thậm chí khiến hình ảnh trình bày trực quan của phần tử thay đổi tương ứng.

<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

Người dùng có thể hiểu mọi thứ mà không cần dựa vào màu sắc không?

Bạn không nên sử dụng màu sắc làm phương tiện duy nhất để truyền đạt thông tin, chẳng hạn như cho biết trạng thái, nhắc người dùng phản hồi hoặc trực quan hoá dữ liệu. Ví dụ: nếu bạn có biểu đồ hình tròn, hãy cung cấp nhãn và giá trị cho từng lát để người dùng bị suy giảm thị lực có thể hiểu thông tin, ngay cả khi họ không thể nhìn thấy nơi các lát cắt bắt đầu và kết thúc:

Độ tương phản có đủ không?

Mọi nội dung văn bản xuất hiện trong thành phần của bạn đều phải đáp ứng ngưỡng tương phản tối thiểu ở cấp WCAG AA. Hãy cân nhắc việc cung cấp giao diện có độ tương phản cao đáp ứng ngưỡng AAA cao hơn, và đảm bảo có thể áp dụng biểu định kiểu tác nhân người dùng nếu người dùng yêu cầu độ tương phản tuỳ chỉnh hoặc màu sắc khác. Bạn có thể sử dụng Trình kiểm tra độ tương phản màu để hỗ trợ khi thiết kế thành phần.

Nội dung đang di chuyển hoặc nhấp nháy có an toàn và dừng được không?

Người dùng phải có quyền tạm dừng, dừng hoặc ẩn nội dung di chuyển, cuộn, hoặc nhấp nháy trong hơn 5 giây. Nhìn chung, hãy tránh cài đặt ROM nội dung.

Nếu thiết bị nào đó phải nhấp nháy, hãy đảm bảo rằng thiết bị đó nhấp nháy không quá 3 lần/giây.

Hoạt động kiểm thử và công cụ hỗ trợ tiếp cận

Có hơn 100 công cụ để bạn đánh giá khả năng tiếp cận của trang web và các thành phần trong đó. Một số công cụ được tự động hoá trong khi một số khác yêu cầu bạn phải kiểm thử thủ công.

Dưới đây là một vài điều bạn nên cân nhắc:

• Axe cung cấp tính năng hỗ trợ tiếp cận tự động thử nghiệm cho khung hoặc trình duyệt bạn chọn. Người mắc rìu có thể được sử dụng để viết kiểm thử khả năng hỗ trợ tiếp cận tự động.

• Hỗ trợ tiếp cận Lighthouse công cụ kiểm tra cung cấp thông tin chi tiết hữu ích để phát hiện các vấn đề thường gặp về hỗ trợ tiếp cận. Điểm số hỗ trợ tiếp cận là giá trị trung bình có trọng số của tất cả các bài kiểm tra khả năng hỗ trợ tiếp cận dựa trên Đánh giá tác động của người dùng Axe. Để giám sát khả năng hỗ trợ tiếp cận bằng quá trình tích hợp liên tục, hãy xem Lighthouse CI.

  

• Tenon.io rất hữu ích khi kiểm thử các vấn đề thường gặp về khả năng hỗ trợ tiếp cận. Tenon hỗ trợ tích hợp mạnh mẽ trên các công cụ xây dựng, trình duyệt (thông qua tiện ích) và thậm chí cả trình chỉnh sửa văn bản.

• Có nhiều công cụ dành riêng cho thư viện và khung để nêu bật vấn đề về khả năng hỗ trợ tiếp cận với các thành phần. Ví dụ: sử dụng eslint-plugin-jsx-a11y để làm nổi bật các vấn đề về khả năng hỗ trợ tiếp cận cho các thành phần React trong trình chỉnh sửa.

  

  Nếu bạn sử dụng Angular, codelyzer cũng cung cấp tính năng kiểm tra khả năng hỗ trợ tiếp cận trong trình chỉnh sửa:

  

Làm việc với các công nghệ hỗ trợ

• Bạn có thể kiểm tra cách các công nghệ hỗ trợ xem nội dung trên web bằng cách sử dụng Trình kiểm tra hỗ trợ tiếp cận (Mac) hoặc Công cụ kiểm tra API Tự động hoá của Windows và AccProbe (Windows). Bạn cũng có thể xem toàn bộ cây hỗ trợ tiếp cận mà Chrome tạo ra bằng cách chuyển đến about://accessibility.
• Cách tốt nhất để kiểm tra khả năng hỗ trợ trình đọc màn hình trên máy Mac là sử dụng VoiceOver tiện ích. Sử dụng ⌘F5 để bật hoặc tắt, Ctrl+Option ←→ để di chuyển qua trang, và Ctrl+Shift+Option + ↑↓ để di chuyển lên và xuống trong chế độ hỗ trợ tiếp cận cây xanh. Để biết hướng dẫn chi tiết hơn, xem danh sách đầy đủ các lệnh VoiceOver và danh sách các lệnh trên web của VoiceOver.

• Trên Windows, NVDA là một màn hình nguồn mở miễn phí người đọc. Tuy nhiên, công cụ này có một đường cong học sâu cho người dùng thị giác.

  

• ChromeOS có trình đọc màn hình tích hợp.

Chúng tôi còn một chặng đường dài phía trước để cải thiện khả năng tiếp cận trên web. Theo Niên giám web:

• Cứ 5 trang web thì có 4 trang web có văn bản hoà vào nền, khiến chúng không đọc được.
• 49,91% số trang vẫn không cung cấp thuộc tính alt cho một số hình ảnh.
• Chỉ 24% số trang sử dụng nút hoặc đường liên kết có nhãn.
• Chỉ có 22,33% số trang cung cấp nhãn cho tất cả thông tin đầu vào trong biểu mẫu.

Chúng tôi có thể làm nhiều để xây dựng những trải nghiệm dễ tiếp cận hơn cho mọi người.