Drupal

Institute on Governance

jesse — Thu, 24 Jun 2010 14:50:11 -0400

The Institute on Governance(IOG) is located here in Canada’s capital city, Ottawa. Its vision is to be the pre-eminent, independent Canadian source of knowledge, research and advice on governance and its continuous improvement. In the past 20 years they have undertaken over 1000 projects in Canada and 35 other countries.

The IOG was looking to update their website with a fresh new and well organized layout, where people could easily and efficiently find the information they were seeking. The IOG regularly releases important publications, hosts events, and offers a variety of educational services such as training courses. It was important to them to be able to feature each of these as highlighted aspects on their website.

OpenConcept has brought all these ideas to fruition, and more. www.iog.ca is now hosted with OpenConcept and is powered by Drupal. The website has been completely reorganized, redesigned and is now bilingual for the first time as well. Highlighted news, events or announcements are now easily updated and featured on the home page as a rotating carousel. Also on the home page is a tabbed section built using the quick tabs module to showcase IOG's Services, Knowledge areas, and Upcoming courses.

Just Vision

Jason — Tue, 22 Jun 2010 11:13:30 -0400

Just Vision is an organization that, through award-winning media, community outreach and an array of educational tools, informs, connects and engages people in Palestinian-Israeli civilian efforts to resolve the conflict nonviolently.

OpenConcept was lucky enough to work with this passionate organization to help them develop a truly unique Drupal-based website. Just Vision had previously implemented another CMS solution and as such, had an existent, complex database that linked interviews from a diverse selection of 'peacebuilders' on a variety of themes. Developing the appropriate taxonomies and linking interviews with themes, footnotes, glossary terms and profiles was challenging but something that Drupal was able to handle well using content types and taxonomies.

You can visit the Just Vision website at http://www.justvision.org

The more challenging aspects of developing the Just Vision site revolved around the Arabic/Hebrew text, which required the use of Tendu(right-to-left Drupal theme). We used the Internationalization module to handle the multilingual content, which worked quite well. However, there were many other areas of the website for which translation proved difficult. Menus, blocks, CCK fields, views, string and taxonomy terms all needed translation and often had different modules for each.

If you are interested in multilingual Drupal development, send us an email and we'd be happy to have a chat! Here is a list of the modules that were used for translation:

Block translation
CCK translation
Content type translation
Internationalization
Localization client
Menu translation
String translation
Taxonomy translation
Translation overview
Language sections
Select translation
Views translation

Recognia

Jason — Thu, 03 Dec 2009 11:47:23 -0500

Recognia provides technical analysis products (interpreted chart recognition) to large brokerage firms worldwide. They help the brokerage firms attract, retain and engage traders by providing actionable research tools.

Recognia came to OpenConcept because they were trying to enhance their web presence with a new website that is more engaging to users, clearly defines the company mandate and product offerings and enables their internal team to take control of content entry.

Drupal was already their content management system of choice and they were excited by the way Drupal could be extended with a vast array of modules, contributed by a vibrant Drupal community. The design was provided by local firm, Sherwin Kaldeway, and themed by our team. Recognia required the website to be developed by OpenConcept using a flexible framework that allows for future development and enhancements. Most importantly they wanted the site to look clean, professional and intuitive to navigate for users.

The site is also to be hosted and supported by OpenConcept. You can visit Recognia's website at www.recognia.com

Final Stretch: Help Needed for Drupal 7 Accessibility

Everett — Tue, 25 Aug 2009 11:14:20 -0400

Yesterday was the third Drupal 7 accessibility taskforce meeting, and the final meeting before code freeze. With September 1 just around the corner the Drupal accessibility community would like to reach out the the broader community for some additional help during this busy time to get as many accessibility improvements into Drupal 7 core as possible.

There are many ways to help and to get involved. If anyone is wondering what they can do or how their skills may be useful please e-mail Everett to find out where your skills can best be put to use.

There are five issues that we would like to request assistance with. They are listed below with links to their issue page.

Thank you so much to everyone who has contributed to Drupal accessibility thus far, and thanks in advance for those who can find the time to contribute over the next week.

Update to the State of Drupal 7 Accessibility

Everett — Wed, 19 Aug 2009 04:14:45 -0400

Introduction

I have been encouraged by the increased participation in the Drupal 7 accessibility issue queue in the past few weeks. There are still a number of outstanding issues that are fundamental to improving the accessibility of Drupal 7. Some of these issues can be dealt with after code freeze, others need to be dealt with before.

I believe that Drupal accessibility has to be adopted and fostered at the grassroots level. Hopefully after code freeze some additional accessibility documentation can be added to Drupal.org and the documentation that is currently on the site can be reordered to make it more useful. I believe that clear and thorough documentation will lower the barrier for entry into the Drupal accessibility arena, making it easier for community members to get involved who currently don't know where to start.

Ongoing Accessibility Challenges

I believe that one of the problems that will continue to persist, even with the best efforts of the Drupal accessibility community, is that accessibility, like usability, CSS, PHP, and SQL, is a specific skill set. Unfortunately, at this time, there are far more community members who possess these other skills than the skills related to accessibility. I imagine that increased documentation and community involvement of those who do possess accessibility skills will help this situation, but also imagine that without the adoption of some form of minimal accessibility standard for Drupal that accessibility will continue to lag behind.

Perhaps the best approach to take, given the current Drupal accessibility landscape, is for the Drupal accessibility community to continue to do its best to educate and assist with accessibility, until there is a threshold level of accessibility awareness within the broader community. At that time, I believe that it will be useful, and achievable, to enforce a minimal accessibility requirement on all patches committed to core. I also believe that it would be useful for community members who are interested in accessibility to raise awareness by asking the question: "How has accessibility been considered for this patch", on any issues involving user interface components. I am happy to make myself available to anyone who has questions about improving the accessibility of core components at everett@openconcept.ca.

Current Accessibility Needs

As far as getting as much accessibility into Drupal 7 core as possible, I want to start by thanking the community, for the support that we have received thus far.

The following, in no particular order, are needs that I have from the broader community to assist me in using my time as efficiently as possible between now and September 1, and even after September 1, so that as much accessibility improvement as possible can be realized.

1. It would be really helpful if when community members notice an accessibility issue that they believe can be dealt with after code freeze that they would add a quick comment. This will help me to better prioritize issues.

2. There are several areas that need work, that I believe will be required before code freeze, A list of the areas, and an idea of resources that would be helpful to me, are listed below, in no particular order.

a. Autocomplete - A brief walkthrough of how the JS events are currently handled so that I can figure out what is causing "undefined" often to be returned for screen-reader users would be useful. I imagine that we will not get ARIA support for autocomplete into Drupal 7, but this may be able to be handled with a contributed module.

b. Table-drag - At the very least some decisions need to be made about where to place an option to disable drag, and what the scope and persistence level of that option will be. It would also be helpful if someone familiar with the code could work with me to roll this patch, as it would save me the time of having to learn how this component works on the code level.

c. Identifying "active" menu item links - I have read through menu_local_tasks() a few times, and am still not certain about which calls to theme('menu_item_link'), ...) are being called for active menu items. It would be helpful if someone familiar with the coding of the menu system could help me to work through this so that I can role a patch for theme_local_task not providing context to screen-reader users.

d. Form element labeling - I am working through all form elements to identify problems with labels, there are currently a number of open issues about form element labeling. My suggested approach is that * every * form element that supports a label (e.g. not button or fieldset) have a label generated, and that a new property be added to all of these elements "#show-label". If the "#show-label" option is false then the label will be styled with .element-invisible so that it does not appear on screen, but will still be accessible to screen-reader users. Wondering if any community members have any thoughts about this approach.

e. Form validation - As I understand it, invalid form fields currently have their labels marked with the class "invalid". I believe that the forms system needs to be modified so that more information is made available within the label for invalid form fields. At the very least an icon, or other structural element that supports text, that indicates that the field is invalid. I believe that this will require a change to how theme_element() currently deals with labeling.

f. Collapsible fieldsets - currently there is no information available to screen-reader users regarding the function of the links used to expand and collapse fieldsets. There is a visual icon, but this is styled as a CSS background image, and cannot have an alt attribute set. My recommendation is that the CSS image be included within the link as an img element, and that the JS switch the class, and alt attribute of the img where it is currently switching the background image. I will need the assistance of someone familiar with the JS involved here to understand the functionality so that I can roll a patch for this issue.

Conclusion

Some important steps toward Drupal 7 accessibility have been achieved thus far, but there is still more work to be done between now and code freeze. I am hoping that the issues listed above, along with many other smaller issues, will be able to be adequately addressed between now and the release of Drupal 7 to ensure that it is a robustly accessible CMS. Not only will improvements to Drupal's accessibility mean a great deal to users with disabilities, but it will also mean more opportunity to use Drupal in government and with other organizations where accessibility is a must.

First Glance Accessibility Evaluation of the d7ux Administration Theme "Seven"

Everett — Tue, 04 Aug 2009 10:45:20 -0400

This morning I had the opportunity to evaluate the accessibility of the d7ux administration theme (Information Architecture) "Seven". My evaluation was not intended to be thorough, or to identify every web accessibility conformance problem, but to get a feel for what the theme will be like for screen-reader users, and what broad accessibility issues need to be addressed.

I must say that from the perspective of a Drupal administrator and screen-reader user that I believe that the theme will be seen as a useful and welcome addition to Drupal 7 by many users. Although there are clearly many accessibility issues to tidy up before Seven is truly accessible, I was surprised at how easy it was to get accustomed to using the iframe "Overlay" panel which appears at the bottom of the page, (if navigated in DOM order).

Methodology and Technologies

I tested Seven, including the d7ux Overlay component, on a clean install of Drupal 7 with no content, logged in as the site administrator.

Browsers used were Firefox 3.5.1 ("FF"), Internet Explorer 6 ("IE") and Safari 4.0.1 ("SA"). Screen-readers used were JAWS 10.0.1154 ("JAWS"), JAWS 6.00.410 ("JAWS6"), NVDA 0.6p3.2 ("NVDA") and VoiceOver - OS X 10.5.7 ("VO").

Where it is not mentioned, Firefox and JAWS 10 were the technologies used. Where a result is not mentioned it can be assumed that a test was not performed. For example, if the report mentions “JAWS and IE repeat the text of the ‘Login’ label.”, do not presume that all other technologies were tested and that they did not demonstrate the same issue. Remember, the observations below are a coarse evaluation of the accessibility of Seven, just to get the ball rolling.

Observations of Seven's Accessibility

I began my evaluation on the empty homepage of the site.

After logging in as the site administrator

1. "Show shortcuts" - this sounds like it should be an actionable item. If it is the heading for the list of links to follow it should give a more descriptive title of the role of the links.

JAWS and JAWS6 on FF and IE, and VO on SA, do not identify this as an actionable item
NVDA does identify this as an actionable item on FF

2. "Hello Admin" and "Logout" immediately proceed the global links - I would expect something more context sensetive to the links above to appear here. I would also expect something more meaningful than “Hello Admin” for link text, where does “Hello Admin” take the user?

3. "Add", "Find content", "Dashboard" - This is a list of links and there are few clues of what the role of the links are. What is being added, what is a dashboard? Presumably these are related to content as the middle link is about content?

4. "My Account", "Logout" - Is this perhaps a little repetitive, how do these links differ from "Hello Admin" and "Logout" above? Are the links above actually necessary? (This is likely more of a usability than accessibility critique.)

After selecting the "Content" link from the top menu

5. After selecting the "Content" link from the top navigational links (top in DOM order, but perhaps not in display order):

JAWS on FF speaks "Content Dialog", but I am left with focus on the "Content" link, I must refresh the JAWS virtual buffer and find the "Content" dialog / iframe (it is a known issue that later updates of JAWS 10 do not correctly unhide elements with style="display: none;").
JAWS6 on IE normally lands near the beginning of the iframe and speaks the element that is landed on, there is no real predicting where JAWS6 will land.
NVDA on FF speaks "Add Content" and I am taken to the add content link, which is disorienting as it is where the bottom of the page used to be.
VO on SA takes me to the “Add content” link and actually treats this as a dialog by “trapping” the user in the iframe until they stop "interacting" with the iframe, by pressing Shift + Control + Option + Up arrow. Unfortunately users will likely not know to do this as VO does not alert the user that they are within a frame.

5.1 Found later in the evaluation, there is content relevant to the “Content” iframe but which is outside of the iframe “Content” “Close button” and links for “Content” and “Comments”.

JAWS and NVDA on FF and JAWS6 on IE do not identify that “Content” or “Comments” are tabs, or which is selected (I imagine that even if these are not visually styled as tabs that they serve the same functional purpose.
VO on SA users do not know that the above options exist because VO traps the user in the iframe, see VO and SA in 5 above.

6. Navigating by headings.

With JAWS and NVDA on FF I find the last heading on the page to be "Welcome to Example Site", and not "Content Administration" or some other heading that would indicate to me that I am now on the section of the page that will allow me to make changes to content.
With JAWS6 on IE there is a heading level 1 “Content” which appears directly before the “Add content” link. This heading would be better placed above the other links mentioned in 5.1 above.

7. The text before the content filter reads "Show only items where" - What items, perhaps "Show content items where" or "Show content that matches the following criteria" would be more meaningful.

8. The Filter controls are within a single item list and then a definition list is being used for some reason, not sure that this is semantically a list, and if it is, there should be more than one list item in the list.

9. "Update Options" is being spoken twice by JAWS, only once by NVDA, and VO on SA.

10. The text before the "Update Options" combobox reads "Update Options". What are "options" being updated for? "Update options for selected items below", may be more meaningful.

11. There is a list of links "Title" ... "Updated".

JAWS and NVDA on FF do not announce this as a table, which I imagine it is, but there is no example data on the site to test with. JAWS and NVDA sometimes do not announce single row tables. Regardless, this should be a table, if it is not, as it would normally contain tabular data.

12. What do each of the table header links do? If the links sort the table by column what is the role of the "Sort icon" link, and should it have a more descriptive alt attribute to describe its role?

JAWS and, NVDA on FF, and JAWS6 on IE read the link text for the table headers and read the last link in the table header as “Sort icon”
VO on SA reads the title attribute for the links, (e.g. “Sort by Title”) and does not find the “Sort icon” link.

After selecting Content > Add Content

13. When on the screen to select the Content type to create:

Link text (e.g. “Article”) is read for content type by JAWS and NVDA on FF, and JAWS6 on IE.
VO on SA reads the title attribute of the link (e.g. “Use articles for time-specific content like news, press releases or blog posts.”), which is repetition of the textual description which appears below.

After selecting the “Article” content type

13.1 User is asked a second time “CHOOSE A CONTENT TYPE:”, I thought I did this on the prior page.

14. With JAWS on FF “the Body” label is being read twice.

15. With JAWS and NVDA on FF, JAWS6 on IE, and VO on SA “the Save and “Preview” buttons are being read twice.

Conclusion

There is still quite a bit of accessibility work to be done on Seven, and more thorough detailed accessibility audits will be necessary to ensure that Seven is a truly accessible administrative theme for Drupal 7. Nevertheless, Seven appears to be well on its way to being one of my favorite new features in Drupal 7, as speaking for only myself here, I believe that it will make day-to-day tasks easier for Drupal 7 administrators.

Script to archive enabled modules

stevem — Mon, 27 Jul 2009 14:02:50 -0400

We use multi-site installations pretty much exclusively. Moving sites around (from development to production, say) can be a pain, especially when there are a large number of modules in sites/all/modules, relatively few of which are used by a given subsite.

I recently turned my hand to using drush to pick out just the enabled modules for a given subsite to make for easy migration. This is my proof of concept script; there is lots of room for improvement.

#!/bin/sh

DOMAIN="domain.tld"
DRUPALROOT="/path/to/drupal"
SCRIPTROOT=`pwd`

# set up tarfiles
TARFILE_ALL="${SCRIPTROOT}/${DOMAIN}_sites.all.modules.tar"
if [ -f $TARFILE_ALL ]; then rm -f $TARFILE_ALL; fi
TARFILE_SITE="${SCRIPTROOT}/${DOMAIN}_sites.${DOMAIN}.modules.tar"
if [ -f $TARFILE_SITE ]; then rm -f $TARFILE_SITE; fi

# tar up modules
cd $DRUPALROOT
for MODULE in `drush --root=$DRUPALROOT --uri=http://$DOMAIN --pipe statusmodules`; do
# sites/all modules
TEST="./sites/all/modules/$MODULE"
if [ -d $TEST ]; then
echo "ALL: $MODULE"
tar --append -f $TARFILE_ALL $TEST
fi

# site-specific modules
TEST="./sites/$DOMAIN/modules/$MODULE"
if [ -d $TEST ]; then
echo "SITE: $MODULE"
tar --append -f $TARFILE_SITE $TEST
fi
done

gzip $TARFILE_ALL $TARFILE_SITE

Common Look and Feel 2.0 and Drupal Collaboration

Everett — Thu, 23 Jul 2009 11:47:29 -0400

Recognizing the need to unify the presentation of governmental information on the web, the Government of Canada has developed CLF 2.0 (Common Look and Feel for the Internet 2.0). Part 2 of CLF 2.0 is the Standard on the Accessibility, Interoperability and Usability of Web Sites. The context for the CLF accessibility standard is that:

Canadians have the right to obtain information and services from Government of Canada Web sites regardless of the technologies they use. The key to effective implementation of universal accessibility lies in designing sites to serve the widest possible audience and the broadest possible range of hardware and software platforms, from adaptive technologies to emerging technologies. (CLF 2.0 Part 2)

Accessibility Compliance

CLF 2.0 requires, with some exceptions, that Government of Canada web-sites conform to the Priority 1 and Priority 2 checkpoints of WCAG 1.0 (Web Content Accessibility Guidelines 1.0, a W3C recommendation). This is not to say that Government of Canada web-sites cannot also implement certain aspects of the newer WCAG 2.0 (Web Content Accessibility Guidelines 2.0). In fact, the IAC/Access Working Group (AWG) will be reviewing WCAG 2.0 to determine how it can be used to improve the accessibility of CLF (Implementation of new CLF 2.0 Standards - Qs and As, 4.2).

Drupal and CLF Accessibility

As I have recently written in State of Drupal 7 Accessibility and Introduction, Drupal 7, and I will add here Drupal 6, are both reasonably accessible out of the box. One of the great benefits of using Drupal from an accessibility perspective is the number of themes available to use to meet a sites needs. Earlier this year Mike wrote about The Eleven Most Accessible Drupal 6 Themes, which is worth a read if you are planning on getting started with Drupal accessible theme design. Two of the amazing benefits of using Drupal are its flexibility and the collaboration of multiple designers all working on a single task. Every bit of markup that is output by Drupal can be customized, so that if it does not currently comply with CLF accessibility standards that it can be made to do so. However, as a site designer you will not be required to make all of these changes yourself. Drupal has an active community of designers and developers who are constantly reviewing issues and making improvements to Drupal's accessibility.

The Benefit of Collaboration

As beneficial as it can be to a government department to receive effortless accessibility improvements to its site, it can also be beneficial for the government to give back to the community by collaborating with Drupal designers and developers within other departments, other levels of government and around the world. Collaboration does not only bring the direct benefit of resolving a particular issue, but also brings new relationships, partnerships and learning opportunities that may otherwise remain unknown. OpenConcept Consulting has been working on a CLF compliant Drupal theme. We have received some great feedback from those who have evaluated the theme and are always endeavoring to improve the theme's compliance. If you would like to provide feedback, or to collaborate, on the CLF Drupal theme please contact Mike Gifford.

Adding Dublin Core Metadata to Drupal

mgifford — Mon, 20 Apr 2009 12:07:55 -0400

This code is now dated because of a release of Nodewords which includes DublinCore Metadata. It's also worth reviewing Smiffy's article on Extensible Metadata for Your CMS

We've been doing a lot of work recently about the Common Look and Feel for the federal government here in Canada. One of the requirements of the CLF has been that documents are created with Dublin Core meta data to allow for it to be more machine readable. This is a great step, and it is nice to be working with an international standard like this. Unfortunately, there didn't seem to be any easy way to produce this meta data with existing modules.

Several people have started developing Dublin Core modules in the Drupal community, but none have finished it. The Meta tags module probably comes the closest as it is designed to produce meta tags for search engine optimization. Unfortunately extending the Meta tag output to allow for a much wider range values isn't presently allowed.

One of the best examples of code provided to allow for Dublin Core that I found was provided on the tech journalist David Fisco's blog. I wanted to have something wrapped into a function in the template.php file so took this and re-wrote it significantly for my needs.

The standard list of available terms within the Dublin Core is a lot larger than what I need for my purposes. I was just looking for a method to provide the basics. abstract, audience, created, creator, date, description, language, license, subject, title would be lots. Some of this can be pulled right from Drupal, I also provided opportunities for using leveraging the Mata tag module and using custom CCK fields as well.

<?php
function phptemplate_preprocess_page(&$vars) {
$current_language = $vars['language']->language;
$vars['dublin_core'] = simple_dublin_core($current_language, $vars['title'], $type, $format, $vars['node']);
}
function simple_dublin_core ($current_language, $title, $type, $format, $node) {
$creator = 'OpenConcept Consulting Inc.';
$publisher = 'OpenConcept Consulting Inc.';
$rights_holder = 'Content Creator';
// Set license & content
$license_notice = 'This article is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.';
$license_content = 'Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.';
// Start producing metadata
$dc_output .= "\n\n" . (!empty($title)) ? '<meta name="dc.title" content="' . $title . "\" />\n" : '';
// Pull values from CCK (if defined)
$cck_subject_field = $node->field_dublin_core_subjects[0]['value'];
$cck_description_field = (!empty($node->field_dublin_core_description[0]['value'])) ? $node->field_dublin_core_description[0]['value'] : $node->field_dublin_core_abstract[0]['value'];
$intended_audience = (!empty($node->field_intended_audience[0]['value'])) ? $node->field_intended_audience[0]['value'] : 'general public';
// Get subject/description through either nodeword module or cck definitions
if (function_exists('nodewords_get')) {
$metatags = nodewords_get('node', $node->nid);
foreach ($metatags as $tagname => $tagcontent) {
if ($tagname == 'keywords') {
$dc_output .= (!empty($tagcontent)) ? '<meta name="dc.subject" content="' . $tagcontent . "\" />\n" : '';
}
if ($tagname == 'description') {
$dc_output .= (!empty($tagcontent)) ? '<meta name="dc.description" content="' . $tagcontent . "\" />\n" : '';
}
}
} else {
// field_dublin_core_subjects: a semi-colon-delimited list of additional subjects you want included in your metadata
$dc_output .= (!empty($cck_subject_field)) ? '<meta name="dc.subject" content="' . str_replace(',', ';', $cck_subject_field) . "\" />\n" : '';
$dc_output .= (!empty($cck_description_field)) ? '<meta name="dc.description" content="' . $cck_description_field . "\" />\n" : '';
$dc_output .= (!empty($node->field_dublin_core_abstract[0]['value'])) ? '<meta name="dcterms.abstract" content="' . htmlspecialchars(ereg_replace("<[^>]*>", "", $node->field_dublin_core_abstract[0]['value'])) . "\" />\n" : '';
}
$dc_output .= (!empty($language)) ? '<meta name="dc.language" scheme="ISO639-2/T" content="' . $language . "\" />\n" : '';
$dc_output .= '<meta name="dc.identifier" scheme="DCTERMS.URI" content="http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] . "\" />\n";
$dc_output .= '<meta name="dc.relation.IsPartOf" scheme="DCTERMS.URI" content="http://' . $_SERVER['HTTP_HOST'] . "\" />\n";
$dc_output .= '<meta name="dc.creator" content="' . $creator . "\" />\n";
$dc_output .= (!empty($publisher)) ? '<meta name="dc.publisher" content="' . $publisher . "\" />\n" : '';
$dc_output .= '<meta name="dcterms.license" content="' . $license_content . "\" />\n";
$dc_output .= '<meta name="dc.rights" content="' . $license_notice . "\" />\n";
$dc_output .= '<meta name="dc.rightsHolder" content="' . $rights_holder . "\" />\n";
// Date of Publication
$dc_output .= (!empty($node->created)) ? '<meta name="dcterms.issued" content="' . date('Y-m-d', $node->created) . "\" />\n" : '';
$dc_output .= (!empty($node->changed)) ? '<meta name="dcterms.modified" content="' . date('Y-m-d', $node->changed) . "\" />\n" : '';
// Could be extended to look at node types
$dc_output .= (!empty($type)) ? '<meta name="dc.type" scheme="W3CDTF" content="' . $type . "\" />\n" : "<meta name=\"dc.type\" content=\"text\" />\n";
$dc_output .= (!empty($format)) ? '<meta name="dc.format" scheme="W3CDTF" content="' . $format . "\" />\n" : "<meta name=\"dc.format\" content=\"text/html\" />\n";
$dc_output .= '<meta name="dc.audience" scheme="gcaudience" content="' . htmlspecialchars(ereg_replace("<[^>]*>", "", $intended_audience)) . "\" />\n";
return $dc_output;
}

Then this just needs to be placed in the header of the page.tpl.php file:

<?php print $dublin_core; ?>

Now there are problems with meta data as Cory Doctorow points out in his article "Metacrap: Putting the torch to seven straw-men of the meta-utopia", the old phrase garbage in, garbage out still applies.

After writing this code I ran into this article for bringing Dublin Core into CCK's Computed Fields and do think there is some more space for collaboration here.

In talking with Matthew Smith about Dublin Core, it became clear that it would also be very logical to pull the description from the teaser and the subject from the taxonomy. Simply exposing the taxonomies in a consistent way would have so many usability advantages.

Building Community and Finding Consensus for Accessibility Enhancements

mgifford — Tue, 03 Mar 2009 07:58:42 -0500

I think there are a number of ways that Drupal 7 could be much more accessible out of the box than it is right now. I've spent a bit of time working on a few items to improve and document some accessibility enhancements. Spent some time going through WCAG 2.0 documentation & comparing it with Drupal Core. And have been making patches and proposing best practices enhancements for a number of projects.

I'm definitely much more of a PHP/MySQL developer, but the complexity of finding a neat solution that works for SEO, across all major browsers, and also with several screen readers is pretty intense. Since more and more websites are needing to comply with accessibility regulations this is going to be a larger problem for all of us. Having a few good best practices outlined and tested in Drupal core will help all of us just implement more accessible websites by default.

The technology is changing quickly, but the guidelines for accessible implementations are as well. Particularly with the more interactive components that have been included into Drupal core, the awareness of ARIA standards will be important. There is a growing community of people participating in the Drupal Groups keen on accessibility issues, but with a mix of experience & expertise.

Building consensus takes time, however, getting a critical mass of people to review patches and demonstrate that they are useful and don't interrupt other functionality isn't easy. Different experts point to different solutions and none of them seem to be looking at specific applications platforms like Drupal. With all of the money that people have invested in generic accessibility initiatives, one would think it would be fairly easy to get support for improving a specific and popular open source implementation that will improve accessibility for everyone (even if an individual developer isn't at all knowledgable about accessibility issues).

I was encouraged though when driving down to DrupalCon in Washington, DC that this is an issue that is being taken more seriously, even at the gas pump. Hopefully we'll be able to get a bit more agreement around these issues in the few days we have at this large conference.

ps. This is also a test to see if this post shows up in Drupal Planet. We're happy to be listed here!