Hướng dẫn này là một phần của Cẩm nang biên soạn của Wikipedia tiếng Việt. Hãy dùng lẽ thường khi áp dụng vì thỉnh thoảng sẽ có ngoại lệ. Hãy đảm bảo rằng bất cứ sửa đổi nào đều phản ánh sự đồng thuận.

Viết tắt CNBS:TIEPCAN WP:KNTC

Tóm tắt trang này: Các trang Wikipedia phải đảm bảo dễ điều hướng và dễ đọc đối với người khuyết tật.

Khả năng tiếp cận web là mục tiêu nhằm làm cho các trang web dễ điều hướng và đọc hơn, chủ yếu để hỗ trợ người khuyết tật; song nó cũng có thể hữu ích cho tất cả độc giả. Chúng tôi mong muốn tuân thủ Nguyên tắc về Nội dung Web Tiếp cận (WCAG) 2.1^[a], một tiêu chuẩn làm cơ sở cho các hướng dẫn dưới đây. Các trang tuân thủ chúng sẽ dễ đọc và sửa đổi hơn đối với mọi người.

Cấu trúc bài viết đúng chuẩn sẽ giúp cải thiện khả năng tiếp cận, vì nó cho phép người dùng mong đợi nội dung nằm trong một phần cụ thể của trang. Chẳng hạn, nếu một người dùng khiếm thị đang tìm kiếm liên kết định hướng và không tìm thấy bất kỳ liên kết nào ở đầu trang, họ sẽ biết rằng không có bất kỳ liên kết nào và họ không cần phải đọc toàn bộ trang để tìm ra chúng.

Việc tiêu chuẩn hóa đã là một thói quen trên Wikipedia, do đó các nguyên tắc cần tuân theo chỉ đơn giản là Wikipedia:Cẩm nang biên soạn/Bố cục và Wikipedia:Cẩm nang biên soạn/Phần mở đầu § Các thành phần.

Đề mục[sửa | sửa mã nguồn]

Đề mục phải mang tính mô tả và tuân theo thứ tự thống nhất như được xác định trong Cẩm nang biên soạn.

Các đề mục phải được lồng nhau theo đúng thứ tự, bắt đầu từ cấp 2 (==), sau đó là cấp 3 (===), v.v. (Cấp 1 là tiêu đề trang được tạo tự động.) Đừng bỏ qua bất cứ phần nào trong trình tự này, chẳng hạn như tùy ý lựa chọn các cấp độ khác nhau nhằm nhấn mạnh; đó không phải là mục đích của việc sử dụng đề mục.

Nhằm mục đích giúp biên tập viên có thị lực kém dễ đọc, trong trình soạn thảo mã nguồn, bạn có thể thêm một dòng trống bên dưới mỗi đề mục, nhưng không nhiều hơn một; đặt nhiều hơn một dòng trống bên dưới đề mục sẽ làm cho khoảng trống thừa được hiển thị trên trang kết xuất ra. Bạn cũng nên suy xét về việc một dòng trống duy nhất bên dưới đề mục có thể xuất hiện trên một màn hình nhỏ đối với một bài viết cụ thể, vì có nhiều biên tập viên sử dụng thiết bị di động để chỉnh sửa và việc có một dòng trống bên dưới đề mục lại có thể làm giảm đi khả năng đọc đối với họ, đối với một số bài viết.

Không tạo đề mục giả bằng cách lạm dụng mã wiki dấu chấm phẩy (dành riêng cho danh sách mô tả) và cố gắng tránh sử dụng mã wiki in đậm. Trình đọc màn hình và công nghệ hỗ trợ khác chỉ có thể sử dụng đề mục có mã wiki đề mục để điều hướng. Nếu bạn muốn giảm đi kích thước của mục lục, hãy sử dụng {{Giới hạn mục lục}}. Trong trường hợp không thể sử dụng {{Giới hạn mục lục}} do các đề mục cấp thấp hơn ở những nơi khác trong bài viết, thì việc sử dụng chữ in đậm cho đề mục con cấp 5 trở xuống là ít gây khó chịu nhất cho người dùng trình đọc màn hình. Sử dụng một tiêu đề giả là rất hiếm gặp, chỉ khi bạn đã không còn phương sách nào khác.

Phần tử nổi [sửa | sửa mã nguồn]

Trong mã wiki, phần tử nổi (bao gồm cả hình ảnh) nên được đặt bên trong mục mà chúng thuộc về; không đặt hình ảnh ở cuối mục liền trước. (Tùy thuộc vào nền tảng, việc "xếp chồng" nhiều hình ảnh cùng với một lượng văn bản tương đối nhỏ có thể khiến một hình ảnh cụ thể bị đẩy xuống phần sau. Tuy nhiên, đây không phải là vấn đề về khả năng tiếp cận vì trình đọc màn hình luôn đọc ra tham số alt= của mỗi hình ảnh tại điểm mà hình ảnh được mã hóa.)

Độ phân giải[sửa | sửa mã nguồn]

Các bài viết Wikipedia cần đảm bảo khả năng tiếp cận đối với độc giả sử dụng thiết bị màn hình nhỏ như điện thoại di động, hoặc độc giả sử dụng màn hình vi tính với độ phân giải thấp. Trên máy tính để bàn, đôi khi đây là một vấn đề xảy ra trong các bài viết có nhiều hình ảnh ở cả hai bên màn hình; mặc dù độ phân giải thấp hơn sẽ làm kéo dài các đoạn văn theo chiều dọc và di chuyển hình ảnh ra xa theo hướng đó, nhưng hãy cẩn thận không thêm hình ảnh hoặc nội dung nổi khác đồng thời trên cả hai bên màn hình. Các bảng và hình ảnh lớn cũng có thể tạo ra vấn đề; đôi khi việc cuộn ngang là không thể tránh khỏi, nhưng hãy cân nhắc tái cấu trúc các bảng rộng để mở rộng theo chiều dọc thay vì theo chiều ngang.

Theo mặc định, hầu hết trình đọc màn hình không thể hiện các thuộc tính văn bản trình bày (đậm, nghiêng, gạch chân, đơn cách, gạch đè) hoặc thậm chí là thuộc tính văn bản ngữ nghĩa (nhấn mạnh, quan trọng, xóa văn bản), vì vậy văn bản bị gạch đè vẫn được đọc ra bình thường giống như bất kỳ loại văn bản nào khác. (Các biên tập viên sử dụng trình đọc màn hình tham gia vào các cuộc thảo luận về quy định và xóa bài trong Wikipedia nên bật thông báo về thuộc tính văn bản khi làm như vậy, vì văn bản bị gạch đè là rất phổ biến trong các cuộc thảo luận nội bộ của Wikipedia.)

Do các trình đọc màn hình thường bỏ qua dấu gạch đè, nên việc sử dụng trong các bài viết, dù hiếm gặp (chẳng hạn, để thể hiện các thay đổi trong một phân tích nguyên văn), sẽ gây ra các vấn đề về khả năng tiếp cận và thậm chí là sự nhầm lẫn hoàn toàn nếu đó là chỉ báo duy nhất được áp dụng. Trường hợp này xảy ra kể cả với phần tử <s> và <del> (cùng với phần tử <ins> tương ứng, vốn thường được hiển thị trực quan dưới dạng gạch chân), cũng như các bản mẫu sử dụng chúng. Không sử dụng gạch đè để phản đối nội dung mà bạn cho là không phù hợp hoặc không chính xác. Thay vào đó, hãy đặt nó giữa hai cặp dấu <!-- và -->, loại bỏ nó hoàn toàn, hoặc sử dụng một bản mẫu dọn dẹp/tranh chấp trong hàng và nêu vấn đề trên trang thảo luận.

Các trình đọc màn hình có mức độ hỗ trợ khác nhau đối với các ký tự ngoài biên mã Latin-1 và Windows-1252, và sẽ không an toàn khi giả định bất kỳ ký tự cụ thể trong phạm vi này sẽ được phát âm như thế nào. Nếu trình đọc màn hình hoặc bộ tổng hợp giọng nói không nhận dạng được chúng, thì chúng có thể được phát âm dưới dạng dấu chấm hỏi hoặc bị bỏ qua hoàn toàn khỏi đầu ra giọng nói.

1. Nên thêm chuyển tự cho tất cả văn bản nằm trong hệ thống chữ viết phi Latinh trong trường hợp cần thiết sử dụng ký tự phi Latinh trong ngữ cảnh gốc như tên, địa điểm, sự vật, v.v. Chức năng này khả dụng trong các bản mẫu biểu thị ngôn ngữ phi Latinh và cũng có thể được tìm thấy trong các bản mẫu như {{transl}}; các bản mẫu này còn có nhiều lợi ích trợ năng khác (xem mục "Ngôn ngữ khác" bên dưới).
2. Không sử dụng các biểu tượng có khả năng không phát âm được như ♥ (biểu tượng trái tim); nên thay bằng hình ảnh có văn bản thay thế.^[1]
3. Các biểu tượng gây ra sự cố cho trình đọc màn hình có thể đã có các bản mẫu được tạo ra để hiển thị hình ảnh và văn bản thay thế, chẳng hạn như bản mẫu dao găm {{†}} (xem thêm trong Thể loại:Bản mẫu chèn hình đơn).

Trình tự các ký tự phải đủ để chuyển tải các khía cạnh ngữ nghĩa của văn bản (cũng như các dạng nội dung tương tự khác); việc dựa vào các "biểu tượng đặc biệt" tùy chỉnh chỉ phân biệt được bằng thuộc tính CSS hoặc mã wiki là không chấp nhận được.

Không sử dụng các kỹ thuật yêu cầu tương tác để cung cấp thông tin, chẳng hạn như chú giải công cụ hoặc bất kỳ văn bản "di chuột" nào khác. Trường hợp ngoại lệ là từ viết tắt, theo đó bản mẫu {{abbr}} (trình bao bọc cho phần tử <abbr>) có thể được dùng để biểu thị dạng đầy đủ của một từ viết tắt (bao gồm từ viết tắt từ chữ đầu).

Không chèn dấu ngắt dòng trong một câu, vì điều này khiến việc chỉnh sửa bằng trình đọc màn hình trở nên khó khăn hơn. Một dấu ngắt dòng đơn có thể theo sau một câu, làm giúp ích cho một số biên tập viên.

Cỡ chữ[sửa | sửa mã nguồn]

Loại cỡ chữ thu nhỏ hoặc phóng to nên hạn chế sử dụng, và chúng thường được áp dụng với các thành phần trang tự động chẳng hạn như đề mục, tiêu đề bảng và các bản mẫu chuẩn hóa. Sự thay đổi về cỡ chữ được chỉ định bằng tỉ lệ phần trăm cỡ chữ ban đầu, chứ không phải cỡ chữ tuyệt đối tính bằng pixel hay cỡ điểm. Kích thước tương đối tăng khả năng tiếp cận cho người dùng khiếm thị bằng cách cho phép họ đặt kích thước phông chữ mặc định lớn (hơn) trong cài đặt trình duyệt của mình. Kích thước tuyệt đối làm mất đi khả năng như vậy của người dùng.

Tránh dùng cỡ chữ nhỏ trong các phần tử trang có sử dụng cỡ chữ nhỏ hơn, ví dụ như hầu hết văn bản trong hộp thông tin, hộp điều hướng và mục tham khảo.^[b] Điều đó có nghĩa là cặp thẻ <small>...</small> và các bản mẫu như {{small}} và {{smalldiv}}, không nên áp dụng cho văn bản thuần túy đặt trong các phần tử đó. Trong mọi trường hợp, cỡ chữ cuối cùng của bất kỳ văn bản nào không được giảm xuống dưới khoảng 85% cỡ chữ mặc định của trang. Lưu ý rằng thẻ HTML <small>...</small> có ý nghĩa ngữ nghĩa là chữ in nhỏ hoặc bình luận bên lề;^[2] không sử dụng nó cho thay đổi về văn phong.

Từ hoặc cụm từ không phải tiếng Việt nên được đặt trong {{lang}}, một bản mẫu sử dụng mã ngôn ngữ ISO 639, theo đó:

{{lang|fr|Assemblée nationale}}

kết xuất thành:

Assemblée nationale

hoặc {{lang-fr|Assemblée nationale}}

kết xuất thành:

tiếng Pháp: Assemblée nationale.

Lý do sử dụng: {{lang}} cho phép bộ tổng hợp giọng nói phát âm văn bản theo đúng ngôn ngữ.^[3] Nó còn có nhiều ứng dụng khác; xem thông tin chi tiết trong Bản mẫu:Lang/doc § Lý do sử dụng

Việc đưa các cấu trúc trên bên trong mã wiki in nghiêng là không cần thiết và không mong muốn; bản thân các bản mẫu {{lang}} và {{lang-xx}} đã tự động in nghiêng sẵn. Nếu văn bản không cần thiết được in nghiêng—chẳng hạn như tên địa danh hoặc tên người—bạn có thể ghi đè cấu hình mặc định bằng cách thêm tham số italic=no.^[c]

Lưu ý rằng nên sử dụng {{transl}} đối với chuyển tự; đối với phát âm nên sử dụng {{IPA}}, {{respell}} hoặc một bản mẫu khác liên quan. {{PIE}} là dành cho tiếng Ấn-Âu nguyên thủy.

Wikipedia còn có một số bản mẫu ngôn ngữ cụ thể như {{lang-zh}} và {{nihongo}}, cung cấp cho biên tập viên các tham số bản mẫu ngôn ngữ cụ thể, chẳng hạn như tùy chọn nhập vào nhiều phương pháp chuyển tự khác nhau. Mặc dù không phải ngôn ngữ nào đều có bản mẫu riêng, bạn được khuyến khích sử dụng các bản mẫu này để tổ chức văn bản wiki tốt hơn thay vì phải xếp chồng bản mẫu {{lang}} và {{transl}} nhiều lần.

1. Hãy tạo mô tả liên kết tốt, đặc biệt là liên kết ngoài (tránh "nhấn vào đây!", "tại đây").^[4][5]
2. Không sử dụng ký tự Unicode làm biểu tượng; thay vào đó, nên dùng biểu tượng với văn bản thay thế. Ví dụ, một ký tự như "→" sẽ không thể được một số trình đọc màn hình chuyển thành văn bản hữu ích.
3. Sử dụng Bản mẫu:Visible anchor nhằm hỗ trợ người suy giảm thị lực định vị mục tiêu liên kết trong trang đích dễ dàng hơn.

Màu sắc thường được tìm thấy nhiều nhất tại các bài viết Wikipedia bên trong các bản mẫu và bảng. Đối với trợ giúp kỹ thuật về hướng dẫn sử dụng màu, xem Trợ giúp:Sử dụng màu.

Bài viết (và các trang khác) có sử dụng màu nên chú ý về khả năng tiếp cận, như sau:

• Đảm bảo rằng màu sắc không phải là phương pháp duy nhất được sử dụng để truyền đạt thông tin quan trọng. Đặc biệt, không sử dụng nền hoặc văn bản có màu trừ khi trạng thái của nó cũng được biểu thị bằng phương pháp khác, chẳng hạn như một biểu tượng tiếp cận được khớp với chú giải, hoặc nhãn cước chú cuối trang. Nếu không, người dùng mất thị lực hoặc độc giả truy cập Wikipedia thông qua bản in hoặc thiết bị không có màn hình màu sẽ không nhận được thông tin đó.
• Các liên kết phải được xác định rõ ràng là liên kết đến với độc giả.
• Một số độc giả của Wikipedia bị rối loạn sắc giác một phần hoặc hoàn toàn, hoặc khiếm thị. Hãy đảm bảo độ tương phản của văn bản với nền của nó đạt ít nhất mức AA của Nguyên tắc về Nội dung Web Tiếp cận (WCAG) 2.0, và mức AAA nếu khả thi (xem phần "Understanding SC 1.4.3: Contrast (Minimum)" của WCAG). Để dùng các màu CSS đã đặt tên cho văn bản trên nền trắng, hãy tham khảo Wikipedia:Cẩm nang biên soạn/Khả năng tiếp cận/Màu CSS cho văn bản trên nền trắng để biết các màu được đề xuất. Ngoài ra, dưới đây là các công cụ có thể được sử dụng để kiểm tra xem độ tương phản có chính xác không:
  • Bạn có thể sử dụng một vài công cụ trực tuyến để kiểm tra độ tương phản màu, ví dụ như công cụ của WebAIM, trang WhoCanUse, hoặc Snook's Color Contrast Check.
    • Trên web còn có thêm nhiều công cụ khác nữa, song trước khi sử dụng, hãy kiểm tra xem chúng đã được cập nhật hay chưa. Một số công cụ được dựa trên thuật toán của WCAG 1.0, trong khi hướng dẫn trên tham khảo theo thuật toán của WCAG 2.0. Nếu công cụ không đề cập cụ thể rằng nó dựa trên WCAG 2.0, hãy giả định rằng nó đã lỗi thời.
  • Nhóm Thiết kế của Wikimedia Foundation đã cung cấp sẵn một bảng màu với các màu được đánh dấu theo hướng về mức tuân thủ AA. Bảng màu này được áp dụng cho tất cả các phần tử giao diện người dùng trên các sản phẩm và trong các chủ đề chính Wikimedia, máy tính để bàn và thiết bị di động. Tuy nhiên, bảng màu không xét đến văn bản được liên kết.
  • Bảng màu trong Wikipedia:Cẩm nang biên soạn/Khả năng tiếp cận/Màu hiển thị kết quả cho 14 sắc độ đi kèm với màu nền tối nhất hoặc sáng nhất tuân thủ mức AAA đối với văn bản chữ đen, chữ trắng, văn bản liên kết và văn bản liên kết đã truy cập.
  • Google Chrome có một trình gỡ lỗi độ tương phản màu với hướng dẫn trực quan và bộ chọn màu.
  • Phần mềm tải về Color Contrast Analyser cho phép bạn chọn màu trên trang, đồng thời phân tích kỹ lưỡng độ tương phản của chúng. Tuy nhiên, hãy đảm bảo chỉ sử dụng thuật toán "độ sáng" (luminosity) mới nhất chứ không phải thuật toán lỗi thời "độ trắng màu/hiệu màu" (color brightness/difference).
• Một số công cụ khác có thể được dùng để giúp tạo biểu đồ đồ họa và bảng phối màu cho bản đồ và những thứ tương tự. Chúng không phải là phương tiện chính xác để xem xét khả năng tiếp cận độ tương phản, nhưng có thể có ích cho các tác vụ cụ thể.
  • Paletton (tên cũ Color Scheme Designer) hỗ trợ chọn một bộ màu tốt cho biểu đồ đồ họa.
  • Color Brewer 2.0 cung cấp các cách phối màu an toàn cho bản đồ kèm theo giải thích chi tiết.
  • Hệ phối màu định tính nhẹ của Paul Tol, gồm một bộ chín màu phù hợp cho người dùng mù màu và kèm với nhãn văn bản đen (cùng nhiều bảng màu khác).
  • Một số công cụ mô phỏng rối loạn sắc giác: Toptal ColorFilter (phân tích trang web), Coblis Color-blindness Simulator (phân tích tập tin nội bộ), NoCoffee (tiện ích trên trình duyệt Firefox, phân tích trang web).
  • Một công cụ mã nguồn mở rất đơn giản và tiện lợi cho việc chọn màu tương phản là Color Oracle, một "trình giả lập mù màu miễn phí cho Windows, Mac và Linux". Nó cho phép bạn xem bất cứ thứ gì trên màn hình của mình giống như cách nó sẽ được nhìn thấy bởi một người nào đó mắc một trong ba loại rối loạn sắc giác hoặc ở thước xám.
• Nếu một bài viết sử dụng màu không đúng cách và bạn không biết cách tự khắc phục, bạn có thể nhờ sự giúp đỡ của các biên tập viên khác.

Tỉ lệ tương phản của màu an toàn cho web so với chữ đen (trên) và trắng (dưới) hoặc ngược lại, với đường viền tại 3 (đỏ), 4,5 (lục) và 7 (lam)

Danh sách liệt kê[sửa | sửa mã nguồn]

Không tách các mục trong một danh sách bằng cách để dòng trống hoặc ngắt cột dạng bảng giữa chúng, kể cả các mục trong một danh sách mô tả (có dấu chấm phẩy hoặc dấu hai chấm đứng đầu; đây cũng là cách định dạng của phần lớn các cuộc thảo luận trong trang thảo luận), danh sách có thứ tự hoặc không có thứ tự. Danh sách vốn dĩ được dùng để nhóm các thành phần thuộc về nhau, nhưng MediaWiki sẽ hiểu dòng trống là phần cuối của một danh sách và bắt đầu một danh sách mới. Ngắt dòng kép quá mức cũng làm gián đoạn trình đọc màn hình, vốn sẽ thông báo ra nhiều danh sách mặc dù thực tế chỉ có một, dẫn đến gây hiểu lầm hoặc nhầm lẫn cho người dùng của các chương trình này. Định dạng không đúng như vậy còn có thể làm tăng thời gian họ cần để đọc danh sách lên gấp ba.

Tương tự, không chuyển đổi giữa các loại mã wiki đánh dấu đầu dòng danh sách (dấu hai chấm, dấu hoa thị hoặc dấu thăng) trong cùng một danh sách. Khi thụt lề để trả lời cho một dòng văn bản bắt đầu bằng bất kỳ tổ hợp dấu hai chấm và dấu hoa thị và đôi khi là dấu thăng, cần phải sao chép bất kỳ chuỗi ký tự nào đã được sử dụng ở trên và nối thêm một ký tự như vậy. Một cách khác là chỉ cần đặt lại lề và bắt đầu một cuộc thảo luận mới (tức là một danh sách HTML mới).

Ví dụ, trong một cuộc thảo luận, làm Y cách sau là hay nhất:

* Đồng ý. Tôi ủng hộ ý tưởng này. —Thành viên:Ví dụ 
** Câu hỏi: Bạn thích gì về nó? —Thành viên:Ví dụ 2
*** Nó có vẻ phù hợp với tinh thần của Wikipedia. —Thành viên:Ví dụ

hoặc Y, trong thảo luận không dấu đầu dòng:

: Đồng ý. Tôi ủng hộ ý tưởng này. —Thành viên:Ví dụ 
:: Câu hỏi: Bạn thích gì về nó? —Thành viên:Ví dụ 2
::: Nó có vẻ phù hợp với tinh thần của Wikipedia. —Thành viên:Ví dụ

Cách sau Y cũng được chấp nhận (ép lại dấu đầu dòng trong câu trả lời):

* Đồng ý. Tôi ủng hộ ý tưởng này. —Thành viên:Ví dụ 
*: Câu hỏi: Bạn thích gì về nó? —Thành viên:Ví dụ 2
*:: Nó có vẻ phù hợp với tinh thần của Wikipedia. —Thành viên:Ví dụ

Tuy nhiên N không làm như sau (chuyển từ danh sách có dấu đầu dòng sang danh sách mô tả):

* Đồng ý. Tôi ủng hộ ý tưởng này. —Thành viên:Ví dụ 
:: Câu hỏi: Bạn thích gì về nó? —Thành viên:Ví dụ 2

hoặc N (chuyển từ danh sách có dấu đầu dòng sang danh sách mô tả):

* Đồng ý. Tôi ủng hộ ý tưởng này. —Thành viên:Ví dụ 
:* Câu hỏi: Bạn thích gì về nó? —Thành viên:Ví dụ 2

hoặc N (để dòng trống giữa các mục của danh sách):

* Đồng ý. Tôi ủng hộ ý tưởng này. —Thành viên:Ví dụ 

** Câu hỏi: Bạn thích gì về nó? —Thành viên:Ví dụ 2

hoặc N (nhảy nhiều hơn một bậc):

* Đồng ý. Tôi ủng hộ ý tưởng này. —Thành viên:Ví dụ 
*** Câu hỏi: Bạn thích gì về nó? —Thành viên:Ví dụ 2

Cách làm sau không được khuyến khích:

: Đồng ý. Tôi ủng hộ ý tưởng này. —Thành viên:Ví dụ 
:* Câu hỏi: Bạn thích gì về nó? —Thành viên:Ví dụ 2

Việc thêm một dấu đầu dòng như trên làm tăng thêm độ phức tạp của danh sách một cách không cần thiết và làm tăng khả năng sử dụng mức thụt đầu dòng sai trong các câu trả lời.

Tách đoạn trong các mục danh sách[sửa | sửa mã nguồn]

Mã đánh dấu danh sách MediaWiki thông thường không tương thích với mã đánh dấu đoạn văn MediaWiki thông thường.

Để đưa nhiều đoạn văn trong một mục của danh sách, hãy Y tách chúng bằng {{pb}}:

* Đây là một mục.{{pb}}Đây là một đoạn văn khác nằm trong mục này.
* Đây là một mục khác.

Việc này cũng có thể làm được Y qua mã đánh dấu HTML rõ ràng cho đoạn văn (chú ý thẻ kết thúc </p>):

* Đây là một mục.<p>Đây là một đoạn văn khác nằm trong mục này.</p>
* Đây là một mục khác.

Trong cả hai trường hợp trên, phải thực hiện toàn bộ Y trong một dòng mã duy nhất. Tuy nhiên, bạn có thể tùy chọn sử dụng kỹ thuật bao lại một mã ngắt dòng bên trong bình luận HTML (để ép nó thành một ngắt dòng đầu ra) nhằm tách đoạn tốt hơn trong chế độ mã nguồn:

* Đây là một mục.<!--
--><p>Đây là một đoạn văn khác nằm trong mục này.</p>
* Đây là một mục khác.

Kỹ thuật này cũng có thể được áp dụng Y cho nhiều dạng thêm vào phần tử khối bên trong một mục danh sách (vì mục danh sách thực chất là phần tử khối, vốn có thể chứa các phần tử khối khác):

* Đây là một mục.<!--
--><p>Đây là một đoạn văn khác nằm trong mục này, và chúng ta sẽ dẫn lời ai đó:</p><!--
-->{{talkquote|Hãy mường tượng đến một thế giới mà trong đó mỗi người có thể tự do tiếp cận khối kiến thức chung của nhân loại.|Jimbo}}<!--
--><p>Đây là một đoạn văn kết thúc nằm trong cùng mục đó.</p>
* Đây là một mục khác.

Xin lưu ý rằng không phải mọi tiêu bản trang hoàng đều có thể được sử dụng theo cách này (ví dụ, một số tiêu bản trích dẫn trang trí được tạo ra dựa vào bảng và trình phân tích cú pháp MediaWiki sẽ không xử lý mã đánh dấu wiki như vậy như khi nằm trong một mục danh sách).

Xem thêm Wikipedia:Cẩm nang biên soạn/Danh sách thuật ngữ đối với hướng dẫn viết mã đánh dấu danh sách mô tả/định nghĩa/kết nối phức tạp.

Không N sử dụng ngắt dòng để mô phỏng các đoạn văn, vì chúng có ngữ nghĩa khác nhau:

* Đây là một mục.<br />Đây là cùng một đoạn văn với ngắt dòng phía trước nó.
* Đây là một mục khác.

Thẻ ngắt dòng là để bao lại bên trong một đoạn văn, chẳng hạn như các dòng thơ (<poem>) hoặc một khối mã nguồn (<syntaxhighlight>).

Không được N dùng dấu hai chấm để cố ăn khớp với cấp độ thụt lề sẵn có, vì (như đã nêu ở trên) nó sẽ tạo ra ba danh sách riêng biệt:

* Đây là một mục.
: Đây là một danh sách hoàn toàn riêng biệt.
* Đây là mục thứ ba.

Một cách khác, bạn có thể Y dùng một trong các bản mẫu danh sách HTML để đảm bảo việc phân nhóm. Kỹ thuật này là tốt nhất đối với việc thêm vào các phần tử khối, chẳng hạn như mã nguồn định dạng, trong danh sách:

{{bulleted list
|1=Đây là một mục:
<pre>
Đây là vài đoạn mã
</pre>
Đây vẫn là cùng một mục.
|2=Đây là mục thứ hai.
}}

Tuy nhiên, kỹ thuật trên không được sử dụng trong các trang thảo luận.

Thụt lề[sửa | sửa mã nguồn]

Một cách tiếp cận mang tính trợ năng đối với thụt lề chính là bản mẫu {{block indent}} đối với nội dung nhiều dòng; nó sử dụng CSS để thụt lề nội dung. Có một số bản mẫu có thể áp dụng được cho việc thụt lề dòng đơn, trong đó có {{in5}} (một bản mẫu toàn cục có cùng tên trên tất cả các trang Wikimedia); chúng giúp thụt lề với nhiều ký tự khoảng trắng khác nhau. Không nên lạm dụng phần tử <blockquote>...</blockquote> hoặc các bản mẫu sử dụng nó (như {{blockquote}} hay còn gọi là {{quote}}) để thụt lề trực quan; chúng chỉ dùng cho nội dung trích dẫn nguyên văn. Bản mẫu thay thế chung {{block indent}} đã được tạo ra cho các trường hợp không phải trích dẫn nguyên văn như trên, cho nên vui lòng sử dụng nó.

Một dấu hai chấm (:) ở đầu dòng sẽ đánh dấu dòng đó làm phần <dd> của một danh sách mô tả HTML (<dl>) trong trình phân tích cú pháp MediaWiki.^[d] Hiệu ứng trực quan thu được trong hầu hết các trình duyệt Web là thụt lề dòng. Dấu hai chấm trên được sử dụng, chẳng hạn, để biểu thị các câu trả lời trong một cuộc thảo luận theo chuỗi trên các trang thảo luận. Tuy nhiên, mã đánh dấu này khi đứng riêng đã thiếu đi phần tử <dt> bắt buộc của danh sách mô tả mà <dd> (mô tả/định nghĩa) gắn liền đến. Như có thể thấy bằng cách kiểm tra mã được gửi tới trình duyệt, điều này dẫn đến HTML bị hỏng (tức là nó không xác thực được^[6]). Kết quả là các công nghệ hỗ trợ, chẳng hạn như trình đọc màn hình, sẽ thông báo một danh sách mô tả không tồn tại, gây nhầm lẫn cho bất kỳ người truy cập nào chưa quen với mã đánh dấu hỏng của Wikipedia. Dấu hai chấm đầu dòng, vì vậy, không phải là lý tưởng về mặt khả năng tiếp cận, ngữ nghĩa hoặc tái sử dụng, nhưng hiện đang được dùng phổ biến, bất chấp các sự cố mà nó gây ra cho người dùng trình đọc màn hình.

Dòng trống không nên được đặt giữa các dòng văn bản thụt lề bằng dấu hai chấm – đặc biệt là trong nội dung bài viết. Phần mềm sẽ hiểu đó là đánh dấu kết thúc một danh sách và bắt đầu một danh sách mới.

Nếu cần thiết có khoảng trống, có hai hướng đi như sau, vốn sẽ cho kết quả khác nhau đối với các trình đọc màn hình:

Cách thứ nhất là thêm một dòng trống với cùng số dấu hai chấm với dòng đứng trên và đứng dưới nó. Đây là cách phù hợp khi hai biên tập viên đang viết ra bình luận ngay sau nhau ở cùng một mức thụt lề. Ví dụ:

: Tôi hoàn toàn đồng ý. —Thành viên:Ví dụ
:
: Tôi không tin. Có nguồn nào tốt hơn không? –Thành viên:Ví dụ 2

Trình đọc màn hình sẽ biết đó là hai mục danh sách (bỏ qua dòng trống).

Cách thứ hai, khi coi nội dung như một bình luận riêng lẻ (hoặc một mục danh sách khác, chẳng hạn, trong văn bản bài viết), là sử dụng mã đánh dấu đoạn văn mới trong cùng dòng đầu ra (xem mục trước đối với các kỹ thuật nâng cao, nhằm thêm vào các khối nội dung phức tạp):

: Văn bản ở đây.{{pb}}Thêm văn bản. —Thành viên:Ví dụ 3

Để hiển thị một công thức hoặc biểu thức toán học trên dòng riêng, bạn nên dùng <math display="block">1 + 1 = 2</math> thay vì :<math>1 + 1 = 2</math>.

Danh sách dọc[sửa | sửa mã nguồn]

Danh sách dọc có dấu đầu dòng[sửa | sửa mã nguồn]

Đối với danh sách dọc có dấu đầu dòng, không nên đặt dòng trống giữa các mục để tách chúng. Thay vào đó, hãy sử dụng bản mẫu pb hoặc mã đánh dấu HTML <p>. (Một dòng trống trước khi bắt đầu danh sách hoặc sau khi kết thúc danh sách sẽ không gây ra vấn đề gì.)

Vấn đề khi đặt dòng trống ở giữa chừng danh sách là nếu các mục được phân cách bởi nhiều hơn một ngắt dòng, danh sách HTML sẽ kết thúc trước ngắt dòng, và một danh sách HTML khác sẽ được tạo ra sau ngắt dòng. Điều này làm những gì trông giống một danh sách duy nhất bị phá vỡ thành nhiều danh sách nhỏ hơn đối với độc giả sử dụng trình đọc màn hình. Ví dụ, với đoạn mã:

* Hoa trắng
* Hoa vàng

* Hoa hồng

* Hoa đỏ

phần mềm sẽ ép khoảng trắng giữa các dòng đi một phần và kết quả trông giống như sau:

• Hoa trắng
• Hoa vàng

• Hoa hồng

• Hoa đỏ

nhưng trình đọc màn hình sẽ đọc thành: "Danh sách gồm 2 mục: (gạch đầu dòng) Hoa trắng, (gạch đầu dòng) Hoa vàng, hết danh sách. Danh sách gồm 1 mục: (gạch đầu dòng) Hoa hồng, hết danh sách. Danh sách gồm 1 mục: (gạch đầu dòng) Hoa đỏ, hết danh sách. "

Không tách các mục trong danh sách bằng thẻ ngắt dòng (<br />). Hãy sử dụng {{liệt kê}} / {{danh sách không dấu đầu dòng}} nếu muốn giữ định dạng danh sách dọc; hoặc suy xét đến {{flatlist}} / {{hlist}} nếu danh sách có thể được kết xuất tốt hơn dưới dạng chiều ngang (trong hàng) như được mô tả trong hai mục sau đây.

Danh sách dọc không dấu đầu dòng[sửa | sửa mã nguồn]

Đối với danh sách không dấu đầu dòng chạy dọc trang theo chiều dọc, có hai bản mẫu {{liệt kê}} và {{danh sách không dấu đầu dòng}} để cải thiện khả năng tiếp cận và ý nghĩa ngữ nghĩa bằng cách đánh dấu những gì rõ ràng là một danh sách thay vì thêm vào ngắt dòng <br />, vốn không nên được sử dụng—xem phía trên. Chúng chỉ khác ở mã wiki được sử dụng để tạo ra danh sách. Lưu ý rằng vì chúng là bản mẫu, nên văn bản trong mỗi mục danh sách không thể chứa biểu tượng dấu gạch đứng (|) trừ khi nó được thay bằng {{!}} hoặc được chứa trong thẻ <nowiki>...</nowiki>. Tương tự, nó cũng không thể chứa dấu bằng (=) trừ khi được thay bằng {{=}} hoặc chứa trong <nowiki>...</nowiki>, mặc dù bạn cũng có quyền vòng qua bằng cách đặt tên cho các tham số (|1=, |2= v.v.) Nếu công việc trở nên quá phức tạp, bạn có thể sử dụng dạng biến thể với bản mẫu {{endplainlist}}. Trong một chú thích, có khả năng bạn sẽ cần đến {{unbulleted list citebundle}}.

{{Liệt kê |
* Hoa trắng
* Hoa vàng
* Hoa hồng
* Hoa đỏ
}}

{{Danh sách không dấu đầu dòng
| Hoa trắng
| Hoa vàng
| Hoa hồng
| Hoa đỏ
}}

Một cách khác, trong các bản mẫu như hộp điều hướng, hoặc bất kỳ vùng chứa phù hợp nào khác, danh sách có thể được tạo kiểu với lớp "plainlist", theo đó:

Trong hộp thông tin, có thể sử dụng:

Xem thêm Cẩm nang biên soạn: Danh sách § Danh sách không gạch đầu dòng.

Danh sách ngang[sửa | sửa mã nguồn]

Đối với danh sách chạy dọc trang theo chiều ngang, cũng như trong các hàng đơn ở hộp thông tin và các bảng khác, có hai bản mẫu {{flatlist}} / {{hlist}} (viết tắt của "horizontal list") để cải thiện khả năng tiếp cận và ý nghĩa ngữ nghĩa. Tính năng này sử dụng đánh dấu HTML chính xác cho từng mục danh sách, thay vì bao gồm các ký tự dấu đầu dòng mà, chẳng hạn, được đọc to rõ (ví dụ, "chấm mèo chấm chó chấm ngựa chấm...") bằng phần mềm hỗ trợ cho người khiếm thị. Chúng chỉ khác ở mã wiki được sử dụng để tạo ra danh sách. Lưu ý rằng khi văn bản được chuyển đến các bản mẫu này (hoặc bất kỳ bản mẫu nào khác), ký tự dấu gạch đứng (|) phải được thoát bằng {{!}}.

{{flatlist |
* Hoa trắng
* Hoa đỏ
** Hoa hồng
* Hoa vàng
}}

{{hlist
| Hoa trắng
| Hoa đỏ
| Hoa hồng
| Hoa vàng
}}

Một cách khác, trong các bản mẫu như hộp điều hướng, hoặc bất kỳ vùng chứa phù hợp nào khác, danh sách có thể được tạo kiểu với lớp "hlist", theo đó:

Trong hộp thông tin, có thể sử dụng:

Đề mục danh sách[sửa | sửa mã nguồn]

Việc sử dụng dấu chấm phẩy không phù hợp để tạo một "đề mục giả" trước một danh sách (hình 1) sẽ tạo một khoảng trống danh sách, và tệ hơn nữa. Dòng có dấu chấm phẩy là một danh sách mô tả gồm một mục và không có nội dung mô tả, tiếp theo là danh sách thứ hai.

Thay vào đó, hãy sử dụng mã wiki đề mục (hình 2).

; Khí hiếm
* Heli
* Neon
* Argon
* Krypton
* Xenon
* Radon

== Khí hiếm ==
* Heli
* Neon
* Argon
* Krypton
* Xenon
* Radon

Bảng[sửa | sửa mã nguồn]

Các trình đọc màn hình và công cụ duyệt web khác sử dụng thẻ đánh dấu bảng cụ thể để giúp người dùng điều hướng dữ liệu có trong chúng.

Hãy dùng cú pháp dấu gạch đứng bảng wiki để tận dụng hết các tính năng có sẵn. Xem meta:Help:Tables để biết thêm thông tin chi tiết về cú pháp đặc biệt được áp dụng cho bảng. Không nên chỉ dùng định dạng, bất kể là CSS hay kiểu mã cứng, để tạo ý nghĩa ngữ nghĩa (ví dụ như thay đổi màu nền).

Nhiều hộp điều hướng, bản mẫu loạt bài và hộp thông tin được tạo ra bằng cách sử dụng bảng.

Tránh dùng thẻ <br /> hoặc <hr /> trong các ô liền kề để mô phỏng một hàng trực quan vốn không được phản ánh trong cấu trúc bảng HTML. Đây là vấn đề đối với người dùng trình đọc màn hình vốn đọc bảng theo ô, hàng HTML theo hàng HTML, không phải hàng trực quan theo hàng trực quan.

Bảng dữ liệu[sửa | sửa mã nguồn]

{|
|+ [văn bản mô tả]
|-
! scope="col" | [tiêu đề cột 1]
! scope="col" | [tiêu đề cột 2]
! scope="col" | [tiêu đề cột 3]
|-
! scope="row" | [tiêu đề dòng 1]
| [ô 1,2] || [ô 1,3]
|-
! scope="row" | [tiêu đề dòng 2]
| [ô 2,2] || [ô 2,3]
...
|}

Mô tả ( |+ )

Phần mô tả chính là tiêu đề bảng, nhằm mô tả bản chất của nó.^[7] Bảng dữ liệu bắt buộc phải có phần mô tả

Tiêu đề dòng và cột ( ! )

Giống như phần mô tả, chúng giúp trình bày thông tin theo cấu trúc hợp lý cho người truy cập.^[8] Tiêu đề giúp trình đọc màn hình kết xuất thông tin tiêu đề về các ô dữ liệu. Ví dụ, thông tin tiêu đề được đọc ngay trước dữ liệu ô, hoặc thông tin tiêu đề được cung cấp theo yêu cầu.^[9] Vì tiêu đề dòng và tiêu đề cột có thể được đọc trước dữ liệu trong mỗi ô khi điều hướng ở chế độ bảng, nên tiêu đề cột và tiêu đề dòng cần xác định duy nhất cột và dòng tương ứng.^[10]

Phạm vi tiêu đề (! scope="col" | and ! scope="row" |)

Cho phép nhận diện tiêu đề là tiêu đề dòng hay tiêu đề cột. Tiêu đề bây giờ có thể được liên kết với ô tương ứng.^[11]

Wikipedia:Cẩm nang biên soạn/Khả năng tiếp cận/Hướng dẫn về bảng dữ liệu cung cấp thêm các yêu cầu chi tiết về:

1. Phần mô tả bảng đúng
2. Cấu trúc tiêu đề đúng
3. Bảng phức tạp
4. Hình ảnh và màu sắc
5. Tránh bảng lồng nhau

Bảng bố cục[sửa | sửa mã nguồn]

Tránh sử dụng bảng để định vị trực quan nội dung không phải dạng bảng. Bảng dữ liệu cung cấp thông tin bổ sung và phương pháp điều hướng vốn có thể gây nhầm lẫn khi nội dung thiếu các mối quan hệ hàng và cột hợp lý. Thay vào đó, hãy sử dụng các phần tử hoặc <div> phù hợp về mặt ngữ nghĩa, cùng với thuộc tính style.

Khi sử dụng bảng để định vị nội dung không phải dạng bảng, hãy giúp trình đọc màn hình xác định đó là bảng bố cục chứ không phải bảng dữ liệu. Đặt thuộc tính role="presentation" bên trong bảng, và không đặt bất kỳ thuộc tính summary nào. Không sử dụng các phần tử <caption> or <th> bên trong bảng, hoặc bên trong bất kỳ bảng lồng nhau nào. Trong mã đánh dấu bảng wiki, điều này có nghĩa là không sử dụng tiền tố |+ hoặc !. Hãy đảm bảo thứ tự đọc của nội dung là chính xác. Các hiệu ứng trực quan, chẳng hạn như căn giữa hoặc kiểu chữ in đậm, có thể thu được qua định kiểu hoặc phần tử ngữ nghĩa. Ví dụ:

{| role="presentation" class="toccolors" style="width:94%"
|-
| colspan="2" style="text-align: center; background-color: #ccf;" | <strong>Văn bản quan trọng</strong>
|-
| The quick || brown fox
|-
| jumps over || the lazy dog.
|}

1. Hình ảnh và biểu tượng không mang tính trang trí thuần túy nên có thuộc tính alt đóng vai trò thay thế cho hình ảnh đối với độc giả khiếm thị, trình thu thập tìm kiếm và người dùng phi trực quan khác. Nếu có văn bản thay thế được thêm vào, văn bản đó phải ngắn gọn hoặc hướng người đọc đến mô tả ảnh hoặc văn bản liền kề. Xem WP:ALT để biết thêm thông tin. Đối với các vấn đề khác cần xem xét về biểu tượng, xem Wikipedia:Cẩm nang biên soạn/Biểu tượng § Lưu ý khả năng tiếp cận của người khiếm thị.
2. Trong hầu hết trường hợp, hình ảnh phải có một ghi chú được tạo thành bằng cú pháp hình ảnh dựng sẵn. Ghi chú này cần mô tả ngắn gọn ý nghĩa của hình ảnh và thông tin cần thiết mà nó đang cố gắng truyền tải.
3. Tránh sử dụng hình ảnh thay cho bảng hoặc biểu đồ. Nếu có thể, bất kỳ biểu đồ hoặc sơ đồ nào cũng phải có văn bản tương đương hoặc phải được mô tả rõ ràng để người dùng không thể nhìn thấy hình ảnh đều có thể hiểu được phần nào về khái niệm.
4. Tránh kẹp văn bản giữa hai hình ảnh hoặc sử dụng kích thước hình ảnh cố định, trừ trường hợp thật sự cần thiết.
5. Tránh dùng thư viện ảnh hỗn độn vì kích thước màn hình và định dạng trình duyệt có thể ảnh hưởng đến khả năng tiếp cận đối với một số độc giả do hình ảnh hiển thị bị phân mảnh. Bài viết có quá nhiều hình ảnh sẽ bị lỗi "hết giờ" trên các phiên bản di động của Wikipedia. Lý tưởng nhất là một trang nên có không quá 100 hình ảnh (bất kể nhỏ như thế nào). Xem MediaWiki:Limit number of images in a page.
6. Tránh đề cập trong văn bản về việc hình ảnh nằm ở bên trái hoặc bên phải. Vị trí hình ảnh có thể khác đối với người xem trang web dành cho thiết bị di động, đồng thời không có ý nghĩa gì đối với những người có các trang được phần mềm hỗ trợ đọc cho họ. Thay vào đó, hãy sử dụng ghi chú hình để xác định hình ảnh.
7. Phần mô tả hình ảnh chi tiết, nếu không phù hợp với một bài viết, nên được đặt trên trang miêu tả của hình ảnh, với một lưu ý rằng nhấp vào liên kết hình ảnh sẽ đưa đến một miêu tả chi tiết hơn. Xem Trợ giúp:Trang miêu tả tập tin § Miêu tả cho hình ảnh.
8. Hình ảnh phải nằm bên trong mục mà chúng có liên quan (ngay sau đề mục và bất kỳ ghi chú đầu mục nào), chứ không phải trong chính đề mục cũng như ở cuối mục trước. Điều này đảm bảo rằng trình đọc màn hình sẽ đọc, và trang web dành cho thiết bị di động sẽ hiển thị, hình ảnh (và văn bản thay thế của nó) trong mục chính xác.
9. Các hướng dẫn trên đã bao gồm văn bản thay thế cho phương trình định dạng LaTeX trong chế độ <math>. Xem Wikipedia:Cẩm nang biên soạn/Toán học § Văn bản thay thế.
10. Không đưa hình ảnh vào trong đề mục, kể cả biểu tượng và mã đánh dấu <math>. Làm như vậy sẽ làm phá vỡ liên kết đến các mục và gây ra một số vấn đề khác.

Hoạt ảnh[sửa | sửa mã nguồn]

Để đảm bảo tính tiếp cận, một hoạt ảnh (GIF) cần phải:

• Có thời lượng không quá năm giây (để tránh trở thành phần tử trang trí thuần túy)^[12] hoặc
• Có tích hợp các chức năng điều khiển (dừng, tạm dừng, phát)^[13]

Như vậy, GIF với hoạt ảnh dài hơn năm giây phải được chuyển đổi sang video (để tìm hiểu thêm, xem hướng dẫn chuyển đổi GIF hoạt ảnh thành Theora OGG).

Ngoài ra, hoạt ảnh không được tạo ra nhiều hơn ba lần nháy sáng trong vòng một giây. Hoạt ảnh nhấp nháy vượt quá giới hạn đó được ghi nhận có khả năng gây co giật.^[14]

Video[sửa | sửa mã nguồn]

Phụ đề có thể được thêm vào video; xem hướng dẫn trong :commons:Commons:Video § Subtitles and closed captioning. Phụ đề có nghĩa là để phiên âm lời nói.

Hiện tại đang có nhu cầu cần phụ đề chi tiết dành cho người khiếm thính. Tính đến tháng 11 năm 2012, điều này là không thể, nhưng tính năng này có thể dễ dàng được thêm vào và đã được yêu cầu trong bugzilla:41694. Phụ đề chi tiết có nghĩa là để được xem thay vì phụ đề. Phụ đề chi tiết cung cấp phiên bản văn bản của tất cả thông tin quan trọng được cung cấp qua âm thanh. Nó có thể bao gồm lời thoại, âm thanh (tự nhiên và nhân tạo), bối cảnh, hành động và biểu cảm của con người và động vật, văn bản hoặc đồ họa.^[15] Nên tham khảo các hướng dẫn ngoài Wikipedia về cách tạo phụ đề chi tiết.^[16]

Ngoài ra, còn có nhu cầu cần phiên bản văn bản của video dành cho người khiếm thị, nhưng tính đến tháng 11 năm 2012 chưa có cách nào thuận tiện để cung cấp văn bản thay thế cho video.

Âm thanh[sửa | sửa mã nguồn]

Phụ đề đối với lời nói, lời bài hát, lời thoại, v.v.^[17] có thể dễ dàng được thêm vào tập tin âm thanh, thông qua phương pháp tương tự như đối với video: :commons:Commons:Video § Subtitles and closed captioning.

Thực hành tốt nhất: mã wiki và lớp CSS[sửa | sửa mã nguồn]

Nói chung, phong cách đối với bảng và các phần tử cấp khối khác phải được thiết lập qua lớp CSS, không phải qua thuộc tính phong cách trong hàng. CSS toàn trang trong MediaWiki:Common.css được kiểm tra cẩn thận để đảm bảo khả năng tiếp cận (ví dụ, đủ độ tương phản màu) và khả năng tương thích với nhiều loại trình duyệt. Hơn nữa, nó cho phép những người dùng có nhu cầu rất cụ thể thay đổi bảng phối màu trong định kiểu của riêng mình (Đặc biệt:MyPage/skin.css, hoặc định kiểu của trình duyệt). Ví dụ, một định kiểu trong Wikipedia:Định kiểu cho người dùng khiếm thị cho ra nền có độ tương phản cao hơn đối với các hộp điều hướng. Vấn đề là khi các lớp mặc định trên toàn trang bị ghi đè, một cá nhân sẽ khó chọn chủ đề của riêng mình hơn rất nhiều.

Việc đảm bảo ngoại quan nhất quán giữa các bài viết và sự tuân thủ hướng dẫn về văn phong cũng tạo ra mức độ chuyên nghiệp cao hơn.

Xét về khả năng tiếp cận, sự lệch hướng ra khỏi các quy ước tiêu chuẩn vẫn có thể chấp nhận được miễn rằng khả năng tiếp cận ấy không bị ảnh hưởng. Cộng đồng nói chung đã cố gắng xây dựng và điều chỉnh nhằm đảm bảo khả năng tiếp cận của phong cách mặc định. Nếu có bản mẫu hoặc hệ phối màu nhất định lệch ra khỏi tiêu chuẩn, tác giả của chúng cần chắc chắn rằng nó đáp ứng các yêu cầu về khả năng tiếp cận, ví dụ như đạt đủ độ tương phản màu cần thiết. Chẳng hạn, hộp thông tin và hộp điều hướng liên quan đến một câu lạc bộ thể thao có thể sử dụng hệ màu vàng và đỏ để phù hợp với màu sắc trang phục của đội. Trong trường hợp này, liên kết màu đỏ sẫm trên nền vàng nhạt cung cấp đủ độ tương phản màu và do đó được xem là tiếp cận được, trong khi màu trắng trên nền vàng hoặc đen trên nền đỏ thì không.

Nói chung, bài viết cần sử dụng mã đánh dấu wiki thay vì một tập hợp hạn chế các phần tử HTML được cho phép. Đặc biệt, không sử dụng các phần tử HTML <i> và <b> để định dạng văn bản; tốt hơn hết, nên dùng mã wiki '' và ''' tương ứng cho kiểu chữ in nghiêng hoặc in đậm, và sử dụng bản mẫu hoặc phần tử đánh dấu ngữ nghĩa đối với trường hợp khác. Cũng nên tránh dùng phần tử <font> trong văn bản bài viết; nên sử dụng {{em}}, {{code}}, {{var}} và các bản mẫu đánh dấu ngữ nghĩa khác khi cần thiết. Để thay đổi cỡ chữ, hãy dùng bản mẫu {{resize}}, {{small}} và {{big}} thay vì cấu hình với thuộc tính phong cách CSS như font-size hoặc phần tử không dùng nữa như <big>. Tất nhiên sẽ có một vài trường hợp ngoại lệ; chẳng hạn, bạn có thể dùng phần tử <u>...</u> để chỉ báo cái gì đó như một liên kết ví dụ vốn không thực sự có thể nhấp được, nhưng trong những trường hợp khác, định dạng gạch chân thường không nên được sử dụng trong văn bản bài viết.

Người dùng có hỗ trợ CSS hoặc JavaScript hạn chế[sửa | sửa mã nguồn]

Phần tử tự thu gọn (thu gọn trước) không nên được sử dụng để ẩn đi nội dung trong phần thân của bài viết.

Bài viết Wikipedia phải tiếp cận được với độc giả sử dụng các loại trình duyệt và thiết bị hạn chế hoặc không hỗ trợ JavaScript hay CSS. Hãy nhớ rằng nội dung Wikipedia có thể được tái sử dụng tự do theo các cách mà chúng ta không thể đoán trước, cũng như được truy cập trực tiếp qua trình duyệt đời cũ. Đồng thời, cần nhận ra rằng không thể cung cấp chất lượng giao diện tương tự cho những người dùng như vậy mà không tránh khỏi các tính năng có lợi cho người dùng với các trình duyệt có khả năng cao hơn một cách không cần thiết. Do đó, bạn không được sử dụng các tính năng có thể khiến nội dung bị ẩn hoặc bị hỏng khi không có CSS hoặc JavaScript. Tuy nhiên, việc suy xét đối với người dùng không có CSS hoặc JavaScript nên được mở rộng chủ yếu để đảm bảo rằng trải nghiệm đọc của họ là có thể, mặc dù chắc chắn sẽ kém hơn.

Lưu ý rằng các phiên bản di động của trang web này không hỗ trợ thu gọn nội dung, do đó bất kỳ nội dung thu gọn được nào thì sẽ tự động được mở rộng.

Để đáp ứng được các vấn đề cân nhắc nêu trên, hãy thử nghiệm bất kỳ thay đổi nào có khả năng gây hại khi tắt JavaScript hoặc CSS. Trong Firefox hoặc Chrome, việc này có thể được thực hiện dễ dàng với tiện ích mở rộng dành cho nhà phát triển web; JavaScript có thể bị tắt trong các trình duyệt khác trong màn hình "Tùy chọn". Cần đặc biệt cẩn thận với các hiệu ứng CSS trong hàng vốn không được một số phiên bản trình duyệt, phương tiện và XHTML hỗ trợ.

Năm 2016, khoảng 7% người truy cập Wikipedia không yêu cầu tài nguyên JavaScript.^[18]

• Usability:Accessibility Initiative (tại Wikimedia)
• Wikipedia:Làm cho bài viết chuyên môn trở nên dễ hiểu
• Wikipedia:Nên và không nên (khả năng tiếp cận)
• Wikipedia:Thông tin kiểm chứng được § Khả năng tiếp cận
• Trợ giúp:Truy cập di động

• Clark, Joe (2003). Building Accessible Websites. New Riders Press. ISBN 0-7357-1150-X. Truy cập ngày 1 tháng 1 năm 2011.
• Pilgrim, Mark (2002). “Dive Into Accessibility: 30 days to a more accessible web site”. Bản gốc lưu trữ ngày 5 tháng 10 năm 2017.
• Patrick J. Lynch; Sarah Horton (2016). Web Style Guide. Yale University Press. ISBN 978-0-300-21165-8. OCLC 1004033147.

• The Wikimedia Design Style Guide
• Recommendations for mobile friendly articles on Wikimedia wikis
• 10 Quick Tips to Make Accessible Web Sites, from WAI
• Colorblind web page filter
• Legibility, from Web Style Guide, 3rd Edition
• Essential Components of Web Accessibility, from WAI
• Introduction to Web Accessibility, from WAI
• Known and tracked MediaWiki accessibility issues