CMS accessibility statements

Noted: Saturday, August 28, 2010 at 21:26:01. Words count: 422.
Last updated: Monday, August 30, 2010 at 11:00:45.

While looking for Web accessibility statements on some content management system (CMS)-blog engines, several searching methods have been tried. Keyword "accessibility" followed by CMS-web-blog engine’s name and accessibility site:[cms or web/blog engine name].com queries are also applied on Google. Do they really care of it?

Drupal accessibility statement has this:


This initiative started with advancements with Drupal 7 accessibility. We have committed to ensuring that all features of Drupal core conform with the Worldwide Web Consortium (W3C) guidelines: WCAG 2.0 and ATAG 2.0. Where possible we will also update the previous version of Drupal core, version 6, to enhance its accessibility…

Accessibility – WordPress Codex:
Accessibility is for everyone, even WordPress users. But what is it?
This page has a lot of useful resources related to universal accessibility and usability concepts.

Joomla accessibility statement (last updated in 2006):

This statement addresses three main areas of accessibility for Joomla!: Sites produced using Joomla! (front end and back end), and the Joomla.org site.

Sites produced using Joomla!

Front end (website)

We will provide a solution capable of delivering accessible websites that comply with WCAG 1.0 Priority 2 and Section 508 requirements by release 1.5 of Joomla!

Back end (admin)

While we will incorporate as many accessibility "features" in the back-end as possible, the technical changes required to reach WCAG compliance at this point would involve an extensive re-write of the code. It would be counter-productive to do this now, as a such a re-write is planned for the 2.x series.

ATutor accessibility:

ATutor includes a variety of features designed to ensure that content is accessible to all potential users, including those with slow Internet connections, older Web browsers, and people with disabilities using assistive technologies to access the Web. These features are described in detail below. Depending on the theme being used, ATutor may include all or some of the features listed here. The default theme includes them all.

It has 16 features listed, such as: bypas/skip links, accesskeys, accessibility verifier, alternative text and navigation, resume/continue feature, hide menus, form labels, form field focus, etc.

For the Textpattern (Txp), I only find this FAQ – Is Textpattern search engine friendly?:

Question: Can I use Textpattern for SEO?
Answer: Yes. Textpattern employs many recommended usability and accessibility techniques, which are friendly to both users and search engines, right out of the box. The default page template is clean, minimal XHTML, with CSS stylesheets linked externally. Textile automatically generates valid XHTML for page content.
Dani Iswara, [myfirstnamelastname]@gmail.com.

9 comments to "CMS accessibility statements"

  1. ArdianZzZ

    Sepertinya eksperimen menutup kolom komentar sudah berakhir ya? :)

    Hehe, mengenai TxP mungkin karena fleksibilitasnya menjadikan CMS satu ini menjadi tidak jelas. Kita dapat membuat output data dalam bentuk/format apapun sesuka hati — bahkan ketika hendak mengekspor isi blogpun, kita musti membuat format sendiri.

    Saya menilai, untuk masalah aksesibilitas pada front end semuanya diserahkan pada desainer. Saya dengar sih banyak yang berpendapat kalau TxP tidak cocok untuk noob.

  2. dani

    Ardianzzz,
    Hasil eksperimennya saya jawab di tulisan terbaru.

    Menurut saya, secanggih apapun suatu CMS, pernyataan aksesibilitas Web bakal menjadi hal yang lumrah–jika tidak mau disebut wajib–bagi para pembuat CMS itu.

  3. ArdianZzZ

    Hehe, sepertinya Dean Allen males tuh bikin…
    Sayang juga sih kalau tidak ada pernyataan resminya — ntar saya cari deh, moga-moga nemu — padahal front end default Textpattern cukup baik dari struktur dokumen, hierarki header, tipografi, hingga fungsi seperti jump link.

  4. dani

    Ardianzzz,
    Struktur Txp lainnya bolehlah. Coba deh hal aksesibilitas itu dicarikan, mungkin ada di suatu tempat.

  5. ArdianZzZ

    Oh ya, menurut Bli, bagaimana dengan diperbolehkannya pengulangan Heading level 1 di HTML5? Saya sendiri tertarik untuk menggunakannya tetapi sepertinya kurang baik dari sisi aksesibilitas ya.

  6. dani

    Ardianzzz,
    Dari sisi aksesibilitas, ada diskusi menariknya di HTML5 to the h1 debate rescue (iheni.com; Henny Swan, Opera Web ‘evangelist’).

    Apa pentingnya sebenarnya menyajikan lebih dari 1 h1?
    Jika ada lebih dari 1 h1, yang mana judul tertinggi?

  7. ArdianZzZ

    Trims linknya. :)
    Penggunaan h1 lebih dari satu sepertinya cukup cocok bagi halaman depan yang menyajikan beberapa ringkasan (excerpt). Akan lebih mudah nantinya — karena saya menggunakan judul tulisan sebagai h1 di halaman tunggal.

  8. dani

    Ardianzzz,
    Menurut saya, HTML5 melihat dari sisi kemudahan penyajian dan distribusi dokumen Web. Misalnya saat dokumen Web ditampilkan di pembaca pasokan/umpanan/’feed’. Tiap ringkasan konten bisa dianggap berdiri sendiri, apalagi jika memakai elemen article yang punya header sendiri.

    Jika dikembalikan ke debat semantik, adakah kelaziman sebuah buku memiliki lebih dari satu judul utama?
    Atau mungkin menunggu kecanggihan pembaca layar komputer dan kebiasaan penggunanya?

  9. ArdianZzZ

    Haha, setuju. Meskipun terdapat beberapa elemen <article> di halaman depan, sebaiknya memang hierarki heading diterapkan secara konvensional saja.