Katherine Lynch.org

Next Saturday, December 10, I will be presenting on responsive accessibility in Drupal at DrupalCamp Chicago 2011.  Check it out:

• My session - Using Drupal for Responsive Accessibility and Design
• Full session schedule
• DrupalCamp Chicago website

DrupalCamp Chicago is a fun, collaborative for learning and brainstorming about Drupal, and even developing for Drupal.  Users, editors, site builders, themers, and developers alike come together to discuss new developments and tutorials for creating awesome Drupal sites.  Hope to see you there!

Here's a little module for creating form elements that allow users to input multiple usernames for that Drupal site as comma-separated values with autocomplete, replicating the experience of free tagging, but with users.  The form value comes through as a string which can be parsed for whatever later on.

To use this, download and activate the module, then when you're building forms in a module, just add this to the array for the field that you want to use as your multi-user autocomplete:

'#autocomplete_path' => 'user/autocomplete/multiple',

Here's an example of what a whole multiple-user-autocomplete field might look like:

$form['administrators'] = array(
    '#type' => 'textfield',
    '#title' => t('Administrators'),
    '#autocomplete_path' => 'user/autocomplete/multiple',
    '#description' => t('Enter multiple names as comma separated values Like name1, name2, name3'),
    '#required' => FALSE,
  );

Download the module here - http://drupal.org/project/multiple_users_autocomplete.

Screenshots

Contact if you have any questions or need support!

History of this module, and credit where credit is totally due

While working on a larger Drupal module, I came across a need for a form element in which the user can input multiple usernames of users on that site as comma-separated values, in a way pretty much identical to how things are handled with the free-tagging taxonomy in Drupal.  After doing some research and shouting into the Twittersphere for help I found out that there is no such thing freely built into Drupal, and thanks to a suggestion from Crell, that a good course of action might be to write this myself, using the free-tagging taxonomy handling in Drupal core as my guide.

Zen is a terrific project out of Drupal.org, written by the extremely talented John Albin.  There are a lot of things that are highly configurable about implementing a Zen subtheme.

An important part of any theme is its cross-browser compatibility.  For most browsers, this isn't a problem, but a need for this type of compliance makes it so that conditional stylesheets are almost always needed for Internet Explorer; the more versions, the more stylesheets (often enough, anyway).

When you create and implement a Zen subtheme, a quick trip through your live page's source will likely show the following:

<!--[if IE]>
<link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/zen/zen/ie.css?C" />
<![endif]-->

This is no big deal generally, but it can be bothersome if you want to start calling your own IE stylesheets.  If you want to add some version-specific IE stylesheets, simply add the following to your subtheme's .info file (see the comments--which are unnecessary in your own .info file--for when each line appears):

; Anything below IE9
conditional-stylesheets[if lt IE 9][all][] = ie7-and-8.css
; IE7 browsers only
conditional-stylesheets[if IE 7][all][] = ie7-only.css
; IE6 browsers and below.  This will also be affected by ie7-and-8.css according to this syntax.
conditional-stylesheets[if lt IE 7][all][] = ie6.css

The second set of brackets is for media queries, so you can specify further there too, I just put "all" in for this example.

After you add this to your .info file AND rebuild your theme registry, you should view something like this in source:

<!--[if IE]>
<link type="text/css" rel="stylesheet" media="all" href="/sites/all/themes/zen/zen/ie.css?9" />
<![endif]-->
<!--[if lt IE 9]>
<link type="text/css" rel="stylesheet" media="text/css" href="/sites/all/themes/MY_THEME/ie7-and-8.css?9" />
<![endif]-->
<!--[if IE 7]>
<link type="text/css" rel="stylesheet" media="text/css" href="/sites/all/themes/MY_THEME/ie7-only.css?9" />
<![endif]-->
<!--[if lt IE 7]>
<link type="text/css" rel="stylesheet" media="text/css" href="/sites/all/themes/MY_THEME/ie6.css?9" />
<![endif]-->

Please note, YOU MUST PUT THE ACTUAL CSS FILE INTO YOUR THEME'S MAIN DIRECTORY IN ORDER FOR THIS TO WORK.  If you just put the conditional stylesheet reference into your directory and try to make this show up before you actually start adding to your CSS file, the conditions won't show up in the header.  They will show up once you add the file.  You'd be surprised how many times I've witnessed someone get hung up on this particular aspect.

Now this is well and good, but you'll see that Zen's ie.css is still being conditionally called here.  Again, not really a problem as it's only used for good, but if you want to override/remove this, go into your subtheme's .info file again and change this line:

; conditional-stylesheets[if IE][all][] = ie.css

to this:

conditional-stylesheets[if IE][all][] = ie.css

That is to say, uncomment it.

If you want to override the file, place your own ie.css file into your subtheme's main directory, filled with all of your own IE-fixy goodness.  If you'd prefer not to call this stylesheet from the Zen theme directory, after uncommenting that line, do not put a file called ie.css into your subtheme's directory.  Once again, if a stylesheet does not exist in your subtheme's directory, the theme engine is not going to waste time setting up a condition for it, so if it's gone from your directory, it's gone from your overhead.

As April 2011, IE6 makes up 2.5% of the browser market, and if you're still working with it, I'll assume it's part of your company's baseline for some weird reason, or you're some kind of programming masochist.  IE7 makes up less than 5%, but is still often programmed for in larger institutions, as small parts of big numbers are still pretty big numbers.  Being able to discard the need to program for IE6 already means a lot less overhead, but IE7 still introduces a host of problems, as does IE8.  IE9 promises to implement a lot more CSS3 and adhere to a lot of web standards, but even right now, requires special stylings.  Keep this in mind when writing your Zen subthemes!

So there's this trend on Twitter on this #FollowFriday (apologies for the hash tag; it's just a force of habit) of people tweeting the Twitter usernames of all the people whom they follow on Twitter and would like to meet in real life.  I took a look at my list and here's what I came up with:

People I follow and would like to meet:

• @clifftyll
• @dboudreau
• @jmspool
• @heyrocker
• @smashing
• @pixeldiva
• @Jennison -> We've met informally at a few Accessibility Camps and meetups
• @tbabinszki
• @NikLP ->I can't believe I still haven't met this guy in person

I follow over 150 people on Twitter.  If that list seems small, it's not because I'm uninterested in anyone, but because I realized, as I was looking at my list, that I've actually met a fair number of the awesomely brilliant people I follow.  Some of them, I'm even fortunate to know in real life.  These include:

My presentation materials for "Theming Views" and "Thich, Rich, and Accessible" (accessible rich media) presentations from DrupalCamp Chicago, June 2010, are available here:

• Theming Views: get it to "look right" - presented at DrupalCamp Chicago, June 2010
  Slides | Abstract
• Thick, Rich, and Accessible: incorporate dynamic content, scripting, and media accessibly - presented at DrupalCamp Chicago, June 2010
  Slides | Abstract

See my Presentations and Posters section for the full listing of my presentations.

So Lullabot has these awesome podcasts that they do with various awesome people in the world of Drupal development.  When I was at DrupalCon San Francisco last month, I was interviewed about my accessibility presentation and my work at Drexel for one.  Here it is:

• Drupal Voices 99: Katherine Lynch on Accessibility Tips for Websites

Some other really cool podcast interviews from DCSF that I highly recommend:

• Everett Zufelt on Accessibility in Drupal
• Jenn Simmons on Usability, CSS3, and Getting Bartik into D7
• Dries Buytaert on the State of Drupal 2010
  
• And my personal favorite, Jack Aponte on Diversity, Power and Privilege in Open Source Communities

Enjoy!

Wrapping up a great, productive DrupalCon San Francisco 2010!  I've created a page with slides and video for my accessibility presentation here:

• Accessibility in Drupal 6 and Drupal 7 by Katherine Lynch

Libraries presentation slides/materials to come. <smiley>

So you know how Wordpress comes with that slick little TinyMCE-based rich text editor built in when you install?  A lot of clients like that, particularly those who do not know any HTML.  The fact that Drupal 6 does not ship with a rich text editor installed in the back end frightens some users, with that big empty "Body:" box and not a single tool to be found.  But they shouldn't be afraid, as there are plenty (PLENTY) of ways to create content for Drupal sites without knowing so much as a tag of HTML.  For this article, we'll focus on rich text editors for the body, particularly FCKEditor.

FCKEditor has been popular for years, and just a few months ago was replaced with CKEditor (a supposedly less suggestive name).  I like CKEditor a lot so far.  It claims full accessibility support as an editing tool (though notably, it claims standards compliance with Section 508 and WCAG 1.0, not 2.0).  I can't verify 100% but I can say that, from what I have tested, it is so far, so accessible.  I liked FCKEditor over TinyMCE for the last few years because it inherently encouraged accessible markup a bit more than TinyMCE.  For instance, data table scoping was way easier in general, with FCKEditor.  Other things like headers and lists came at least as naturally as with any other editor.  

I've had a fair number of Drupal 6 clients who like FCKEditor and want to keep it installed for the time being, so I generally use the actual Drupal FCKEditor module for the job, for the reasons outlined above, plus client preference.  It should be noted, however, that a completely stable release of the Drupal CKEditor module is available now and is continuing to be updated/improved for Drupal 6.  Give it a try, you'll like it! (Hey Mikey!)

Now one thing that end user admins tend to want is an ability, similar to that within Wordpress, to upload local images into their content.  With Wordpress's built-in media library, the user clicks the little "add an image to your media library" icon, browses their local files and selects what they want, uploads it, fills out the information, and boom, image-riddled blog post.  It's quite easy to replicate this accepted workflow in Drupal 6.  And here it is:

The newly-registered #drupal-accessibility channel is open and ready for accessibility-related development discussion and conversation.  I'm setting up logging so we can possibly use it to document things like conf calls and other Drupal chats related soon.
Check it out:

• Drupal IRC channels listing
• #drupal-accessibility
• How to use IRC