ARIA: chất độc hay thuốc giải độc?

Việc nói dối với trình đọc màn hình sẽ chữa trị được những tình trạng khuyết tật như thế nào trong khi việc nói dối không làm vào đó được!

ARIA là gì?

ARIA cho phép các tác giả web tạo ra một thực tế khác mà chỉ trình đọc màn hình mới nhìn thấy 🤥

Đôi khi, cần phải mở rộng sự thật hoặc thậm chí là "nói dối" một cách thẳng thắn với trình đọc màn hình về những gì đang xảy ra trong nội dung web. Ví dụ: "tiêu điểm thực sự ở đây!" hoặc "đây thực sự là một thanh trượt!". Việc này giống như việc thêm ghi chú cố định kỳ diệu lên trên các công cụ và tiện ích trên bàn làm việc. Những ghi chú cố định kỳ diệu này khiến mọi người tin rằng những gì mình đang viết trên đó.

Bất cứ khi nào một ghi chú cố định kỳ diệu tồn tại, ghi chú đó sẽ ghi đè niềm tin của chúng ta về ý nghĩa của mỗi công cụ hoặc về điều gì đó về công cụ. Ví dụ: "Cái thứ này ở đây là một khẩu súng bắn keo!". Mặc dù thực sự chỉ là một chiếc hộp màu xanh dương trống trên bàn làm việc, nhưng ghi chú cố định kỳ diệu sẽ khiến chúng ta thấy đó là một khẩu súng keo. Chúng tôi cũng có thể thêm "và đã đầy 30%!". Lúc này, trình đọc màn hình sẽ báo cáo rằng có một khẩu súng keo đầy đủ 30% ở đó.

Web tương đương với việc này là lấy một phần tử hộp thuần tuý (div) chứa một hình ảnh bên trong và sử dụng ARIA để cho biết đó là một thanh trượt với giá trị 30/100.

ARIA không phải là gì?

ARIA không ảnh hưởng đến giao diện của trang web hoặc hành vi của người dùng chuột hoặc bàn phím. Chỉ người dùng công nghệ hỗ trợ mới nhận thấy sự khác biệt so với ARIA. Nhà phát triển web có thể thêm bất kỳ ARIA nào tuỳ ý mà không ảnh hưởng đến những người dùng hiện không chạy công nghệ hỗ trợ.

Bạn đã đọc đúng: ARIA không thực sự làm gì đối với tiêu điểm bàn phím hoặc thứ tự thẻ. Tất cả được thực hiện trong HTML, đôi khi được tinh chỉnh bằng một chút JavaScript.

ARIA hoạt động như thế nào?

Trình đọc màn hình hoặc công nghệ hỗ trợ khác sẽ yêu cầu các trình duyệt cung cấp thông tin về từng phần tử. Khi ARIA xuất hiện trên một phần tử, trình duyệt sẽ lấy thông tin và thay đổi nội dung mà trình đọc màn hình thông báo về phần tử đó.

Tại sao nên dùng ARIA?

Tại sao chúng tôi lại muốn nói dối người dùng của mình!?

Giả sử cửa hàng trực tuyến địa phương không bán tất cả các tiện ích chúng ta cần. Nhưng, chúng tôi là MacGyver, thật tuyệt! Chúng ta có thể phát minh ra các tiện ích của riêng mình từ các tiện ích khác! FWIW, 7 thứ được sử dụng nhiều nhất của MacGyver là dao, kẹo cao su, dây giày, que diêm, kẹp giấy, nến sinh nhật và băng keo dán. Anh ấy sử dụng chúng để chế tạo bom và những thứ khác không chỉ nhằm mục đích bố trí. Điều này khá giống với một tác giả web cần tạo thanh trình đơn. Các thanh trình đơn hữu ích đến mức bạn nghĩ chúng sẽ là một phần của HTML, nhưng thực tế lại không phải vậy. Ôi! Bạn có nghĩ là các tác giả sẽ hài lòng với các liên kết và nút bạn không? Vì vậy, tác giả sẽ sắp xếp chúng lại với nhau bằng các công cụ yêu thích: div, hình ảnh, kiểu, trình xử lý lượt nhấp, trình xử lý thao tác nhấn phím, nhổ và ARIA.

Đôi khi, thay vì sử dụng ARIA ở mức tối đa, chúng tôi chỉ sử dụng ARIA như một tính năng nâng cao. Bạn nên rắc thêm một chút ARIA lên một số HTML mà về cơ bản đã hoạt động. Ví dụ: chúng ta có thể muốn một thành phần điều khiển biểu mẫu trỏ đến một cảnh báo lỗi liên quan đến một số giá trị nhập không hợp lệ. Hoặc chúng ta có thể muốn cho biết rằng hộp văn bản là dành cho việc tìm kiếm. Những tinh chỉnh nhỏ này có thể giúp các trang web thông thường trở nên hữu ích hơn với trình đọc màn hình.

Ví dụ về thanh trình đơn

Hỗ trợ những người nhấp chuột

Hãy cùng tạo thanh trình đơn. Chúng tôi hiển thị một loạt các mục trong các phần tử hộp chung được gọi là div. Bất cứ khi nào người dùng nhấp vào một div, công cụ sẽ thực thi lệnh tương ứng. Thật tuyệt, ứng dụng này hoạt động cho những người nhấp chuột!

Tiếp theo, chúng ta sẽ tạo giao diện đẹp mắt. Chúng tôi sử dụng CSS, tức là kiểu, sắp xếp mọi thứ sao cho đẹp mắt và đặt đường viền hình ảnh xung quanh chúng. Chúng tôi làm cho nó trông giống như các thanh trình đơn khác mà người dùng có thể nhận biết một cách trực quan rằng đó là thanh trình đơn và cách sử dụng nó. Thanh trình đơn của chúng tôi thậm chí sử dụng một màu nền khác cho bất kỳ mục nào mà chuột di chuyển qua, cung cấp cho người dùng một số phản hồi trực quan hữu ích.

Một số mục trong trình đơn là phần tử mẹ. Chúng tạo ra các trình đơn con con. Bất cứ khi nào người dùng di chuột vào một trong các trình đơn này, chúng tôi sẽ bắt đầu một ảnh động trượt ra trình đơn con con.

Tất nhiên, tất cả những điều này gần như không thể truy cập được, như trường hợp thông thường của nhiều nội dung trên web, phần lớn là do trình hướng dẫn tiêu chuẩn HTML không thêm mọi thứ mà tác giả web cần. Và ngay cả khi họ đã làm, tác giả trang web sẽ luôn muốn phát minh ra phiên bản đặc biệt của riêng họ.

Hỗ trợ tiếp cận bàn phím thanh trình đơn

Đối với bước đầu tiên về khả năng hỗ trợ tiếp cận, hãy thêm tính năng hỗ trợ tiếp cận bằng bàn phím. Phần này chỉ sử dụng HTML chứ không sử dụng ARIA. Hãy nhớ rằng ARIA không ảnh hưởng đến các khía cạnh cốt lõi như giao diện, chuột hoặc bàn phím của những người dùng không có công nghệ hỗ trợ.

Giống như một trang web có thể phản hồi chuột, nó cũng có thể phản hồi bàn phím. JavaScript của chúng tôi sẽ lắng nghe tất cả các thao tác nhấn phím xảy ra và quyết định xem thao tác nhấn phím có hữu ích hay không. Nếu không, trình mô phỏng sẽ gửi nó trở lại trang như một con cá quá nhỏ để ăn. Chúng tôi có các quy tắc như:

• Nếu người dùng nhấn phím mũi tên, hãy xem bản thiết kế thanh trình đơn nội bộ của chúng ta và quyết định mục nào trong trình đơn đang hoạt động mới nên là. Chúng tôi sẽ xoá mọi vùng nổi bật hiện tại và làm nổi bật mục mới trong trình đơn để người dùng nhìn thấy được họ đang ở đâu. Sau đó, trang web sẽ gọi event.preventDefault() để ngăn trình duyệt thực hiện thao tác thông thường (trong trường hợp này là cuộn trang).
• Nếu người dùng nhấn phím Enter, chúng ta có thể xử lý phím đó giống như một lượt nhấp và thực hiện thao tác thích hợp (hoặc thậm chí là mở một trình đơn khác).
• Nếu người dùng nhấn một phím để thực hiện thao tác khác, đừng ăn phím đó! Đưa nội dung đó trở lại trang như dự định. Ví dụ: thanh trình đơn của chúng ta không cần phím Tab, vì vậy, hãy trả lại! Đây là điều khó để chính xác và các tác giả thường làm lộn xộn. Ví dụ: thanh trình đơn cần các phím mũi tên, nhưng không cần Alt + Mũi tên hoặc Command + Mũi tên. Đó là các phím tắt để di chuyển đến trang trước/tiếp theo trong lịch sử web trên thẻ trình duyệt của bạn. Nếu tác giả không cẩn thận, thanh trình đơn sẽ chọn các món ăn đó. Loại lỗi này xảy ra rất nhiều và chúng tôi thậm chí chưa bắt đầu sử dụng ARIA!

Quyền truy cập của trình đọc màn hình vào thanh trình đơn

Thanh trình đơn được tạo bằng băng keo và các div. Do đó, trình đọc màn hình không biết bất kỳ nội dung nào. Màu nền của mục đang hoạt động chỉ là một màu. Các div mục trong trình đơn chỉ là các đối tượng thuần tuý không có ý nghĩa cụ thể. Do đó, người dùng thanh trình đơn của chúng tôi không nhận được bất kỳ hướng dẫn nào về phím cần nhấn hoặc mục đang ở trên.

Nhưng điều đó không công bằng! Thanh trình đơn hoạt động tốt đối với người dùng bình thường.

ARIA để giải cứu. ARIA cho phép chúng ta giả sử trình đọc màn hình rằng tiêu điểm đang nằm trong một thanh trình đơn. Nếu tác giả đã làm đúng mọi thứ, thanh trình đơn tuỳ chỉnh của chúng ta sẽ được sử dụng trong trình đọc màn hình giống như thanh trình đơn trong ứng dụng dành cho máy tính.

Đầu tiên, ARIA nói dối là sử dụng thuộc tính aria-activedescendant và đặt thuộc tính này thành mã nhận dạng của mục trình đơn đang hoạt động, hãy cẩn thận cập nhật bất cứ khi nào thuộc tính này thay đổi. Ví dụ: aria-activedescendant="settings-menuitem". Phần nằm nhỏ màu trắng này khiến trình đọc màn hình coi mục đang hoạt động của ARIA là tiêu điểm, nội dung này được đọc to hoặc hiện trên màn hình chữ nổi.

Quay lại aria-activedescendant. Bằng cách sử dụng cử chỉ này để trỏ từ thanh trình đơn được lấy tiêu điểm đến một mục cụ thể trong trình đơn, trình đọc màn hình giờ đây sẽ biết vị trí mà người dùng đã di chuyển, ngoài thông tin nào khác về đối tượng đó. Vậy thì điều này là gì? Đây là lúc cần có thuộc tính vai trò. Chúng ta sử dụng role="menubar" trên phần tử chứa cho toàn bộ, sau đó sử dụng role="menu" trên các nhóm mục và role="menuitem" trên ... đánh trống ... các mục riêng lẻ trong trình đơn.

Và nếu mục trong trình đơn có thể dẫn đến một thực đơn con thì sao? Người dùng cần biết điều đó, đúng không? Đối với người dùng bình thường, có thể thấy một hình tam giác nhỏ ở cuối trình đơn, nhưng trình đọc màn hình chưa biết cách tự động đọc hình ảnh, ít nhất là vào thời điểm này. Chúng ta có thể thêm aria-expanded="false" trên mỗi mục trình đơn có thể mở rộng để cho biết 1) có nội dung nào đó có thể mở rộng và 2) nội dung đó hiện không được mở rộng. Khi thêm một chi tiết, tác giả nên đặt role="none" vào hình tam giác hình ảnh để cho biết rằng thông tin này chỉ nhằm mục đích làm giả. Điều này ngăn trình đọc màn hình nói bất cứ điều gì về hình ảnh vốn là thừa và có thể gây khó chịu.

Xử lý lỗi

Lỗi bàn phím (HTML!)

Mặc dù quyền truy cập bằng bàn phím là một phần của HTML cốt lõi, nhưng các tác giả luôn làm rối nó, vì họ không sử dụng quá nhiều điều hướng bằng bàn phím hoặc do có nhiều sự tinh vi trong việc xác định.

Ví dụ về lỗi:

• Hộp đánh dấu sử dụng phím cách để bật/tắt, nhưng tác giả đã quên gọi preventDefault(). Lúc này, phím cách sẽ chuyển cả hộp đánh dấu và trang xuống, đây là hành vi mặc định của trình duyệt cho phím cách.
• Một hộp thoại phương thức ARIA muốn giữ lại thao tác điều hướng bằng thẻ bên trong đó và tác giả quên cho phép trình duyệt Control+Tab cụ thể. Giờ đây, tổ hợp phím Control + Tab chỉ di chuyển trong hộp thoại và không chuyển đổi các thẻ trong trình duyệt theo cách thông thường. Hừm.
• Tác giả tạo một danh sách lựa chọn và triển khai thao tác lên/xuống, nhưng không triển khai thao tác điều hướng trên trang chủ/cuối/trangup/pagedown hoặc chữ cái đầu tiên.

Tác giả phải tuân theo các mẫu đã biết. Hãy xem phần Tài nguyên để biết thêm thông tin.

Đối với các vấn đề thuần tuý về truy cập bàn phím, bạn cũng nên thử mà không dùng trình đọc màn hình hoặc tắt chế độ trình duyệt ảo. Trình đọc màn hình thường không cần thiết để phát hiện các lỗi bàn phím và việc truy cập bằng bàn phím thực sự được triển khai bằng HTML chứ không phải ARIA. Xét cho cùng, ARIA không ảnh hưởng đến nội dung cơ bản như hành vi của bàn phím hoặc chuột, mà chỉ ảnh hưởng đến trình đọc màn hình về nội dung trên trang web, nội dung hiện đang được lấy tiêu điểm, v.v.

Lỗi bàn phím hầu như luôn là lỗi trong nội dung web, cụ thể là trong HTML và JavaScript, chứ không phải trong ARIA.

Lỗi ARIA: tại sao lại có nhiều như vậy?

Có rất nhiều nơi mà tác giả có thể nhận ARIA không chính xác và mỗi nơi sẽ dẫn đến lỗi hoàn toàn hoặc khác biệt nhỏ. Những vấn đề tinh vi có thể sẽ tệ hơn vì tác giả sẽ không phát hiện được hầu hết chúng trước khi xuất bản.

Suy cho cùng, trừ phi tác giả là người dùng có kinh nghiệm về trình đọc màn hình, sẽ có vấn đề xảy ra trong ARIA. Trong ví dụ về thanh trình đơn, tác giả có thể cho rằng vai trò "option" được sử dụng khi "menuitem" là chính xác. Họ có thể quên sử dụng aria-expanded, quên đặt và xoá aria-activedescendant vào đúng thời điểm hoặc quên có thanh trình đơn chứa các trình đơn khác. Còn số lượng món trong thực đơn thì sao? Thông thường, các mục trong trình đơn được trình đọc màn hình hiển thị dưới dạng "mục 3/5" để người dùng biết họ đang ở đâu. Con số này thường được trình duyệt tính tự động, nhưng trong một số trường hợp và trong một số tổ hợp trình đọc màn hình của trình duyệt, các con số không chính xác có thể được tính và tác giả cần phải ghi đè các con số này bằng aria-posinset và aria-setsize.

Và đây chỉ là thanh trình đơn. Hãy nghĩ xem có bao nhiêu loại tiện ích. Nếu muốn, bạn có thể xem nhanh thông số kỹ thuật của ARIA hoặc các phương pháp soạn thảo. Đối với mỗi mẫu, có rất nhiều cách mà ARIA có thể bị sử dụng sai mục đích. ARIA dựa vào thông tin về tác giả để biết họ đang làm gì. Điều gì có thể xảy ra khi hầu hết tác giả không phải là người dùng trình đọc màn hình?

Nói cách khác, người dùng trình đọc màn hình thực tế cần 100% phải dùng thử các tiện ích ARIA trước khi được xem là có thể vận chuyển. Nội dung có quá nhiều chi tiết. Tốt nhất là bạn nên thử mọi cách với một số cách kết hợp trình đọc màn hình trình duyệt, do có nhiều cách triển khai khác nhau cũng như một vài cách triển khai chưa hoàn chỉnh.

Tóm tắt

Tóm lại, ARIA có thể được dùng để ghi đè hoặc thêm vào mọi nội dung và mọi nội dung mà HTML nêu. Bạn có thể dùng API này để thực hiện những thay đổi nhỏ đối với bản trình bày hỗ trợ tiếp cận hoặc để tạo ra toàn bộ trải nghiệm. Đây là lý do tại sao ARIA vừa cực kỳ mạnh mẽ vừa nguy hiểm dưới bàn tay của các tác giả web thân thiện tại địa phương của chúng tôi, những người này thường không sử dụng trình đọc màn hình.

ARIA chỉ là một lớp đánh dấu ghi đè (sự thật) đơn giản. Khi trình đọc màn hình hỏi điều gì đang xảy ra, nếu ARIA có tồn tại, thì trình đọc sẽ nhận được phiên bản ARIA của sự thật thay vì sự thật cơ bản thực tế.

Phụ lục 1: Tài nguyên khác

Tham chiếu kết hợp với các ví dụ về mã và thông tin về bàn phím

• Các phương pháp tạo tác giả ARIA của W3C: tài liệu này ghi lại các đặc điểm điều hướng bằng bàn phím quan trọng của từng ví dụ và cung cấp mã JS/CSS/ARIA đang hoạt động. Các ví dụ này tập trung vào những gì hoạt động hiệu quả hiện nay và không bao gồm thiết bị di động.

Phụ lục 2: ARIA được sử dụng nhiều nhất cho mục đích gì?

Vì ARIA có thể thay thế hoặc bổ sung những sự thật nhỏ hoặc lớn, thường hữu ích khi nói những nội dung mà trình đọc màn hình quan tâm.

Sau đây là một số cách sử dụng ARIA phổ biến.

• Tiện ích đặc biệt không tồn tại trong HTML, chẳng hạn như thanh trình đơn, tính năng tự động hoàn thành, cây hoặc bảng tính
• Các tiện ích tồn tại trong HTML, nhưng tác giả vẫn phát minh ra tiện ích của riêng mình, có thể là vì họ cần điều chỉnh hành vi hoặc giao diện của tiện ích thông thường. Ví dụ: một phần tử HTML <input type="range"> về cơ bản là một thanh trượt, nhưng các tác giả lại muốn phần tử này trông khác. Trong hầu hết trường hợp, bạn có thể sử dụng CSS, nhưng đối với input type="range", CSS rất khó sử dụng. Tác giả có thể tạo thanh trượt của riêng mình và sử dụng role="slider" trên thanh trượt đó với aria-valuenow để cho biết giá trị hiện tại là gì.
• Các khu vực trực tiếp sẽ cho trình đọc màn hình biết "ở khu vực này của trang, mọi thay đổi đều đáng thông báo cho người dùng".
• Mốc quan trọng (hiện tại HTML có các cột tương đương). Các thẻ này có phần giống với tiêu đề, vì chúng giúp người dùng trình đọc màn hình tìm thấy nội dung họ muốn nhanh hơn. Tuy nhiên, chúng khác nhau ở chỗ chứa toàn bộ phần liên quan. Chẳng hạn như "vùng chứa này là khu vực chính của trang" và "vùng chứa này ở đây là bảng điều hướng".

Phụ lục 3: API Hỗ trợ tiếp cận là gì?

API hỗ trợ tiếp cận là cách trình đọc màn hình hoặc AT khác biết được nội dung trên trang và tình huống đang xảy ra. Ví dụ: MSAA, IA2 và UIA. Và đó chỉ là Windows! Một API hỗ trợ tiếp cận có 2 phần:

• Một "cây" gồm các đối tượng đại diện cho hệ phân cấp vùng chứa. Những con búp bê này giống như búp bê làm lồng của Nga, nhưng mỗi con búp bê có thể chứa nhiều con búp bê khác. Ví dụ: một tài liệu có thể chứa nhiều đoạn và một đoạn văn có thể có văn bản, hình ảnh, đường liên kết, chữ in đậm, v.v. Mỗi mục trong cây đối tượng có thể có các thuộc tính như vai trò (tôi là gì?), tên/nhãn, giá trị do người dùng nhập, nội dung mô tả cũng như các trạng thái boolean như có thể làm tâm điểm, làm tâm điểm, bắt buộc, đã đánh dấu. ARIA có thể ghi đè bất kỳ thuộc tính nào trong số này. Trình đọc màn hình sử dụng cây để giúp người dùng di chuyển ở chế độ vùng đệm ảo, chẳng hạn như "vui lòng chuyển đến tiêu đề tiếp theo".
• Một loạt các sự kiện xảy ra khi mô tả các thay đổi đối với cây, như "lấy nét hiện ở đây!". Trình đọc màn hình sử dụng các sự kiện để cho người dùng biết điều gì vừa xảy ra. Khi mã đánh dấu HTML hoặc ARIA quan trọng thay đổi, một sự kiện sẽ được kích hoạt để cho trình đọc màn hình biết rằng có nội dung nào đó đã thay đổi.

Thông thường, các tác giả chỉ sử dụng HTML, vốn ánh xạ tốt đến các API hỗ trợ tiếp cận này. Khi HTML chưa đủ, ARIA sẽ được dùng và trình duyệt sẽ ghi đè ngữ nghĩa HTML trước khi gửi cây đối tượng hoặc sự kiện đến trình đọc màn hình.