Log in

Accessify Forum - Accessibility Discussion

Latest Tweets

W3C Releases Unicorn, an All-in-One Validator http://ow.ly/18jtbB #accessibility #a11y #axs - Gary

3 days ago, RT: @mpaciello RT @w3c

@msmousette You’re welcome, Liz! – @dotjay

22/07/2010

@Elin012 Sorry for delay. The study has now ended. They were after native English-speaking, 18+, not visually or cognitively disabled.

22/07/2010

From @msmousette: “Many thanks to everyone who helped [with the web study] - they had a great response.” –@dotjay

22/07/2010

Native-English speakers: Able to help with a 15 min. accessibility web study? http://www.accessifyfo...@dotjay

21/07/2010

Read more...

Currently Online

No registered users are online.

accessible cms project

  • Reply to topic
  • Post new topic

Home / News & Resources / accessible cms project

Reply with quote "Open Publisher" is a content management system which first development goal is to provide a user friendly and accessible admin interface. It is based on php5 and mysql.
There is still no release available but you can test a preview installation online.

Test website:
http://test.smart3.org

Test website admin login:
http://test.smart3.org/...

This test installation comes with a minimal configuration. Which means that not all functions are enabled. It was tested under Firefox and Lynx. IE7 makes some trouble and i hope i can fix this soon.
You have two alternatives to format text content. TinyMce and Text_Wiki.
The System was designed to switch between many admin interface layouts. In a long term it is possible to build admin interfaces for people with specific requirements .

For now the focus is on the the current admin interface. This project needs help from accessibility experts and people who share their experience.

Open Publisher is distributed under the LGPL License.

Critics and suggestions are welcome!

Thanks,
Armand
Reply with quote Nobody interested?. Is any body happy with existing systems?
Reply with quote Hi Armand,

This looks like a really good project - I'm sure the lack of response so far doesn't reflect a lack of interest!

It all looks pretty solid to me. Couple of initial comments:
  • I notice from the Help section that you're using accesskeys - I'd usually discourage these as they can conflict with other functions and are rarely intuitive.
  • Also, when publishing an article is there a way to skip all of the formatting options in the body field? There are 38 of them, which could get quite tiring (when tabbing)!
James
_________________
James Coltham - Local gov web manager by day, web and accessibility blogger at lunchtime, freelancer by night. Tweets at @prettysimple.
Reply with quote The markup it generates seems pretty good overall. There are some normal misconceptions about improving your markup by adding more attributes and following "hype":
  1. Uses an XHTML 1.0 Transitional DOCTYPE for text/html documents. These cannot be processed as XML in web browsers. You should use HTML 4.01 Strict.
  2. Random characters between links where list markup would be a better fit:
    1. Using . between the skip links.
    2. Using - between YAML and Sitemap in the footer.
  3. Lots of title attributes in places where they harm usability. For examples:
    1. title="administration links bar" on your navigation. If you hover the mouse over a navigation link, say Archive a tooltip says administration links bar which doesn't make sense.
    2. Using title="site article search" on both the <label> and the <input> for the search form and title="search in site articles" on the form itself. Also, the <input> has placeholder text search. Imagine the repetition all this will cause in text-to-speech browsing, and the plethora of tooltips it causes for sighted pointer users!
    3. Incidentally, this <label> is associated with the <input> both implicitly through nesting and explicitly through for+id. But it has no text content to associate! Very Happy
    4. Using title which repeats the link text for pagination links at the bottom of main content.
  4. Along similar lines, the use of lang is excessive in places:
    1. Using lang="en" in nav_main is redundant as all the ancestors have inherited lang="en" from the <html> element.
    2. Uses lang on all 3 elements in each "Latest published articles" entry. Putting it on the <li> instead would remove 2 instances per foreign-language entry.
  5. Overuse and underuse of headings. Accessibility Archive content starts with <h2>Accessibility</h2> then has <h3>Articles</h3>. Did you mean <h2>Accessibility Articles</h2>, perhaps?
  6. Use of technical labelling and overqualified timestamps instead of user-friendly writing. For example, Publish date: 2008-03-06 20:33:01 followed by Modify date: 2008-03-11 19:27:32 instead of Published on 6th March 2008, updated on 11th March 2008.
Similar mistakes are present in the admin interface, particularly the use of title. You don't need skip links throughout the admin interface. Headings provide the necessary structure for users to navigate the page in assistive devices.

But don't feel bad! I see these sorts of mistakes a lot. There's certainly space in the market for an accessible CMS. There are several projects trying to achieve this. But a CMS is a huge undertaking, so you might be more productive helping an existing project.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Reply with quote Thanks James for your reply!

James wrote:
Hi Armand,

This looks like a really good project - I'm sure the lack of response so far doesn't reflect a lack of interest!


Well, it is hard to awak interests for such a project. I think there is a need for such a project but the response in general so far is nearly 0.

James wrote:

  • I notice from the Help section that you're using accesskeys - I'd usually discourage these as they can conflict with other functions and are rarely intuitive.
  • Also, when publishing an article is there a way to skip all of the formatting options in the body field? There are 38 of them, which could get quite tiring (when tabbing)!
James


It is possible to disable accesskey support in the general settings and user related settings. You are right, under some circumstances accesskeys conflict with other applications.

Do you mean the tinymce editor in the body field? This editor has some accessibility features which are described here:
http://wiki.moxiecode.com/...

armand
Reply with quote Many thanks for your critics Cerbera. Thats exactly what i expected all the time!

I have noticed all the points.

Cerbera wrote:

For examples:[list=a][*]title="administration links bar" on your navigation. If you hover the mouse over a navigation link, say Archive a tooltip says administration links bar which doesn't make sense.


I cant find the point 3.a. you mentionned? Where is it located?

Cerbera wrote:

4. Along similar lines, the use of lang is excessive in places:


Open Publisher was designed to build multilanguage projects. So it could be possible to mix several articles and navigation nodes of different languages on a single page. Therefore each article and node has its own language attribute. I dont know how this could be a problem. Does it?

Cerbera wrote:

You don't need skip links throughout the admin interface. Headings provide the necessary structure for users to navigate the page in assistive devices.


Does it means that skip links dont make sense in any case?

Cerbera wrote:

There are several projects trying to achieve this. But a CMS is a huge undertaking, so you might be more productive helping an existing project.


I couldnt find any cms project who seriously takes care of accessibility. Which projects do you mean? All existing projects that i know have not only problems with accessibility but also in its core architecture design. I started with this project 3 years ago. Now it is in a stade where it becomes interesting. So i wouldnt switch to an other project.

armand
Reply with quote Oops, 3a should say title="main site navigation".

It's excellent that you support multiple languages. Point 4 in my message was about providing a single lang per entry 3 lang attributes. There's also a huge amount of whitespace, which adds filesize.

For example, you currently have this:
Code:
                                                            <li>
                                                                            <a href="http://test.smart3.org/id_article/8" lang="fr">Promesse non tenue</a>
                                                                                                                <p class="date" title="date of publication" lang="fr">2008-03-04</p>
                                                                            <p title="article description" lang="fr">Le dernier David Cronenberg, « Eastern Promises », déçoit par une mise en scène mal ficelée, en dépit des idées et des images superbes.</p>
                                                                    </li>
It could be optimised to this:
Code:
<li lang="fr">
 <a href="http://test.smart3.org/id_article/8">Promesse non tenue</a>
 <p class="date" title="date of publication">2008-03-04</p>
 <p title="article description">Le dernier David Cronenberg, « Eastern Promises », déçoit par une mise en scène mal ficelée, en dépit des idées et des images superbes.</p>
</li>
From 735 bytes down to 326 bytes, 55% more efficient. Cool

1 or 2 skip links as the very first items on the page can be useful but nowhere else. And this usefulness is decreasing because assistive technologies and mobile phones are making better use of the structures in HTML.

Wordpress produces pages with reasonable accessibility. XStandard has done a lot of work into generating accessible pages and having an accessible backend. Wordpress and Joomla! seem to have a reasonable backend but I'm not a programming expert. But after 3 years of hard work, I can appreciate your desire to continue with this system!
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Reply with quote Hi Cerbera,
You are right, there could be less white spaces. Before a page is sended to the browser, it is compressed. So in fact, the amount of bytes transfered to you are far less (30%-50%) than the real page amount in bytes.

About Wordpress and Joomla.
Of course you can do a lot with Wordpress but it is still a blogging system, not a cms. In complex projects you touch on its limits.
Joomla has done a lot of progress in its core architecture. Nevertheless it transports old baggage.

What i'm looking for is, accessibility in backends. How serious they take care for this? How accessible are all this hundreds of extensions, modules,.... Is there a master concept or strategy of all about the accessibility concerns? My experience with such software is, that accessibility is some where in the atmosphere, but there is no real strategy.

The administration layout that you can see in Open Publisher (the test site) is one of many possible admin layouts. It is my propose and its may not the best propose. I could imagine that some one else has a far better propose. But the difference of many existing cm-systems is that Open Publisher can run several admin concepts (not only layouts, but concepts) at the same time (user depended). For a future version i'm planning a concept which is optimized for the lynx browser. May some one else has a nice idea to build a concept which makes use of all this ajax stuff.

All this is possible because the system has a clear separation of layers (mvc) and a modular structure.

One of the strategy is that accessibility should have a strong focus. Never i will accept a module which dosent care of accessibility.

But of course, i'm not superman and therefore it needs people who are willing to spend their time in this project.

Armand
Reply with quote
atu wrote:
Is there a master concept or strategy of all about the accessibility concerns? My experience with such software is, that accessibility is some where in the atmosphere, but there is no real strategy.
Hmm, well observed. Accessibility (and even the basic usability) of Joomla modules and components seems to range from bad to diabolical. Fostering a community where that is avoided would be another worthwhile aspect to your project.

I can provide occasional markup reviews as above, but I can't commit anything beyond that.
_________________
My CV type thing and my Life of Ben (Blog). Nigel Peck's Accessify Forum Requirements.
Reply with quote
Cerbera wrote:

I can provide occasional markup reviews as above, but I can't commit anything beyond that.


Many thanks. I will remember your offer!

Armand
Reply with quote To get interest going you would at least need a downloadable system and a selection of templates. Is this available?
Reply with quote
cantthinkofanickname wrote:
To get interest going you would at least need a downloadable system and a selection of templates. Is this available?


A downloadable version will be available soon. The system has not yet the user and programmers community of existing systems like typo3 or drupal. So there wont be hundreds of template examples available. The next version comes with 2 template examples.

  • Reply to topic
  • Post new topic

Display posts from previous:   

All times are GMT

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum