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

Việc cải thiện khả năng truy cập sẽ 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à ai cũng có thể truy cập được. Có ít nhất 6 lĩnh vực khuyết tật chính mà bạn có thể tối ưu hóa để cải thiện: thị giác, nghe, 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 ích cho bạn, ngay cả khi bạn chưa biết gì về khả năng hỗ trợ tiếp cận trên 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ác trang web cần phải hoạt động trên nhiều thiết bị với nhiều kích thước màn hình và nhiều loại đầu vào, chẳng hạn như trình đọc màn hình. Hơn nữa, các trang web phải được nhóm người dùng rộng nhất sử dụng, bao gồm cả những người khuyết tật.

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

Vấn đề về hình ảnh, bao gồm từ việc không phân biệt được màu sắc cho đến không nhìn thấy được.

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

Bản thân tôi sống với thị lực kém và tôi thường phải phóng to 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ợ tính năng thu phóng hầu như không bao giờ là ưu tiên hàng đầu trong danh sách việc cần làm của các nhà phát triển, nhưng nó có thể tạo ra sự khác biệt cho những người dùng như tôi.

Vấn đề về thính giác có nghĩa là người dùng có thể gặp vấn đề khi nghe âm thanh phát ra từ một trang.

• Cung cấp các lựa chọn 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 trên giao diện người dùng vẫn hoạt động không có âm thanh.

Vấn đề về khả năng di chuyển có thể bao gồm việc không thể thao tác với chuột, bàn phím hoặc màn hình cảm ứng.

• Làm cho nội dung của các thành phần giao diện người dùng có thể truy cập chức năng từ bàn phím cho bất kỳ thao tác nào mà người dùng sẽ dùng chuột để thực hiện.
• Đảm bảo các trang được đánh dấu chính xác cho các 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ác chế độ điều khiển công tắc vật lý) có xu hướng sử dụng cùng một API.

Vấn đề về nhận thức cho thấy người dùng có thể cần đến công nghệ hỗ trợ để giúp họ đọc văn bản. Vì vậy, bạn cần đảm bảo có các lựa chọn thay thế cho văn bản.

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

  Truy vấn nội dung nghe nhìn CSS prefers-reduced-motion giúp bạn giới hạn ảnh động và tự động phát video cho những 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 các tương tác dựa trên thời gian.

Có vẻ như có nhiều cơ sở cần đề cập, nhưng chúng ta sẽ hướng dẫn từng bước về quy trình đánh giá và sau đó cải thiện khả năng tiếp cận của các thành phần trê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ố nên và không nên làm. Bạn có thể dùng những áp phích này để 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 trên giao diện người dùng

Khi kiểm tra khả năng hỗ trợ tiếp cận của các thành phần giao diện người dùng trên trang, hãy tự hỏi những điều sau:

• 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 các bẫy lấy nét không? Chrome có thể phản hồi các sự kiện thích hợp liên quan đến bàn phím 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 trực quan 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ủa bạn 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ủa bạn có thể hoạt động mà không cần màu sắc không?

  Đảm bảo người không nhìn thấy được màu sắc có thể sử dụng thành phần giao diện người dùng của bạn. Một công cụ hữu ích giúp mô phỏng mù màu là một tiện ích của Chrome có tên Colorblindly. (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 tiện ích Daltonize, tiện ích này 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ể hỗ trợ phần 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ó khả năng hỗ trợ tiếp cận được tích hợp trong trình duyệt. Chúng có thể làm tâm điểm bằng cách sử dụng phím Tab; phản hồi với các sự kiện trên bàn phím (như Enter, Space và các phím mũi tên); đồng thời có vai trò, trạng thái và thuộc tính 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 các quảng cáo này cũng phải đáp ứng các yêu cầu về hỗ trợ tiếp cận nêu trên.

Bạn cần cung cấp 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 các phần tử chuẩn như <button>) không tích hợp sẵn tính năng nào, bao gồm cả khả năng hỗ trợ tiếp cận. Bạn nên bắt đầu khi triển khai chức năng hỗ trợ tiếp cận là so sánh thành phần của mình với một phần tử chuẩn tương tự (hoặc kết hợp nhiều phần tử chuẩn, tuỳ thuộc vào độ phức tạp của thành phần).

Hầu hết các công cụ cho nhà phát triển trình duyệt đều hỗ trợ 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, thông tin 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 mà bạn có thể tự hỏi khi tìm cách 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à hãy đảm bảo rằng bạn có thể truy cập tất cả chức năng trong thành phần giao diện người dùng bằng bàn phím. Khi thiết kế trải nghiệm người dùng, hãy nghĩ về cách bạn sẽ sử dụng riêng phần tử với bàn phím và tìm ra các tổ hợp tương tác nhất quán với bàn phím.

Trước tiên, hãy đảm bảo rằng bạn có mục tiêu trọng tâ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ột mục tiêu tâm điểm trong một trang, nhưng sau đó phải quản lý tiêu điểm trong chính thành phần đó để mục trong trình đơn đang hoạt động luôn được lấy làm tâm điểm.

Sử dụng chỉ mục thẻ

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

Các phần tử tương tác được tích hợp sẵn (chẳng hạn như <button>) có thể được đặt làm tâm điểm ngầm, do đó, các phần tử này không cần thuộc tính tabindex trừ khi bạn cần thay đổi vị trí của các phần tử đó theo thứ tự thẻ.

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

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

Đối với các thành phần giao diện người dùng tuỳ chỉnh, hãy luôn sử dụng giá trị tabindex là 0 hoặc -1, vì bạn sẽ không thể xác định trước thứ tự các phần tử trên một trang nhất định. Giá trị tabindex là -1 đặc biệt hữu ích để quản lý tiêu điểm trong các thành phần phức tạp.

Đảm bảo tiêu điểm luôn hiển thị, cho dù bằng cách sử dụng kiểu vòng lấy nét mặc định hay áp dụng kiểu tiêu điểm tuỳ chỉnh rõ ràng. Hãy nhớ không mắc kẹt người dùng bàn phím – họ phải 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ử cụ thể sẽ tự động lấy tiêu điểm khi trang được tải. autofocus đã được hỗ trợ trên mọi chế độ điều khiển biểu mẫu trên web, bao gồm cả các nút. Để tự động lấy nét 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, hãy gọi phương thức focus(). Phương thức này được hỗ trợ trên mọi 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

Khi thành phần giao diện người dùng của bạn có thể được lấy làm tâm điểm, hãy cung cấp câu chuyện tương tác phù hợp với bàn phím khi một thành phần được lấy làm tiêu đ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 tuỳ 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 cung cấp một số hướng dẫn tại đây.

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

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

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

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

Tất cả các thành phần và hình ảnh có lựa chọn văn bản thay thế có ý nghĩa không?

Bất cứ khi nào thông tin 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, hãy cung cấp một văn bản thay thế 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à trình đơn cài đặt, thì thành phần đó cần một văn bản thay thế có thể truy cập được, chẳng hạn như phần "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 phương án thay thế văn bản 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 bóng. Bạn có thể tìm thấy các mẹo kỹ thuật chung trong Tài liệu 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 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ó 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 thị giác bằng các tín hiệu hình ảnh, 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ó trình duyệt tích hợp thông tin ngữ nghĩa này, nhưng đố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ày.

Nhìn chung, bất kỳ thành phần nào nghe sự kiện nhấp chuột hoặc di chuột đều phải 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ác trạng thái và thuộc tính ARIA.

Ví dụ: một thành phần giao diện người dùng <fancy-slider> tuỳ chỉnh có thể nhận vai trò ARIA của thanh trượt, trong đó 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ị của phần tử và thậm chí khiến giao diện hình ảnh 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 thức duy nhất để truyền tải 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 phần để người dùng khiếm thị có thể hiểu được thông tin, ngay cả khi họ không thể 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 hiển thị 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 độ tương phản AA WCAG. Cân nhắc việc cung cấp một 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 bảng 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ể dùng Trình kiểm tra độ tương phản màu này để hỗ trợ khi thiết kế thành phần.

Nội dung chuyển động hoặc cài đặt ROM có thể dừng và an toàn không?

Người dùng phải 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. Nói chung, tránh nội dung nhấp nháy.

Nếu có mục nào đó phải nhấp nháy, hãy đảm bảo rằng mục đó 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ụ có sẵn để đánh giá khả năng tiếp cận trang web của bạn và các thành phần trên đó. Một số công cụ được tự động hoá trong khi một số khác yêu cầu kiểm thử thủ công.

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

• Axe cung cấp hoạt động kiểm thử khả năng hỗ trợ tiếp cận tự động cho khung hoặc trình duyệt mà bạn chọn. Bạn có thể dùng Axe Puppeteer để viết chương trình kiểm thử khả năng hỗ trợ tiếp cận tự động.

• Bài kiểm tra tính năng Hỗ trợ tiếp cận Lighthouse 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ề khả năng hỗ trợ tiếp cận. Điểm số về khả năng hỗ trợ tiếp cận là điểm trung bình có trọng số của tất cả các lượt kiểm tra khả năng hỗ trợ tiếp cận dựa trên thông tin đánh giá tác động của người dùng Axe. Để theo dõi khả năng hỗ trợ tiếp cận bằng cách 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ề 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í là trình chỉnh sửa văn bản.

• Có nhiều công cụ dành riêng cho khung và thư viện để làm nổi bật các vấn đề về 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ề hỗ trợ tiếp cận cho các thành phần React trong trình chỉnh sửa của bạn.

  

  Nếu bạn sử dụng Angular, codelyzer cũng sẽ 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ông nghệ hỗ trợ

• Bạn có thể kiểm tra cách mà các công nghệ hỗ trợ xem nội dung 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 bằng cách chuyển đến about://accessibility.
• Cách tốt nhất để kiểm thử tính năng hỗ trợ trình đọc màn hình trên máy Mac là sử dụng tiện ích VoiceOver. Sử dụng ⌘F5 để bật hoặc tắt tính năng này, Ctrl+Option ←→ để di chuyển qua trang và Ctrl+Shift+Option + ↑↓ để di chuyển lên và xuống cây hỗ trợ tiếp cận. Để biết hướng dẫn chi tiết hơn, hãy xem danh sách đầy đủ các lệnh của VoiceOver và danh sách các lệnh trên Web của VoiceOver.

• Trên Windows, NVDA là một trình đọc màn hình nguồn mở, miễn phí. Tuy nhiên, đối với người dùng thông thường, phương pháp này cần nhiều kiến thức.

  

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

Chúng tôi còn một chặng đường dài để 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 pha trộn 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ó cả nhãn.
• Chỉ 22,33% số trang cung cấp nhãn cho tất cả thông tin đầu vào của biểu mẫu.

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