Accessible “Read More” Links

When there are a bunch of “read more” links on a page, it is usually fairly obvious from visual cues what the “read more” refers to. However, when screen reader users encounter a bunch of “read more” links on a page, it is not always obvious which part of the page each “read more” link refers to. A simple solution is to use a bit more descriptive text than simply “read more” and use CSS to hide the additional text. In this example the following code is used.

<p><a href="#">Read more <span class="offscreen">About NC State</span></a></p>

This is the CSS rule.

.offscreen {
position:absolute;
left:-999px;
width:1px;
height:1px;
top:auto;
}

Notes:

• The off-screen text needs to be included in the <a> as well, otherwise it won’t be read correctly by screen readers.
• You cannot use the CSS rule display:none or visibility:hidden as that will make the content invisible to screen reader users.
• This code is not unique to me. It is the compilation of different examples I have seen in various accessibility forum posts. I just want to put this example in writing for others.

Autocomplete off - (Custom Module)

'Autocomplete off' Module work on these forms - user login, user profile, user_register, user_pass.

Download Module

Form Autocomplete off

function autocomplete_form_user_login_alter(&$form, &$form_state) {
$form['#attributes']['autocomplete'] = 'off';
}

Web Accessibility Evaluation Tools & Links

1. http://achecker.ca/checker/index.php
2. http://validator.w3.org/checklink
3. http://validator.w3.org
4. http://jigsaw.w3.org/css-validator
5. adesigner tool
6. http://sixrevisions.com/web-standards/accessibility_testtools/
7. http://wave.webaim.org/
8. http://www.w3.org/WAI/RC/tools/complete

Clear cache URL or menu link

Create a new page, with the input filter set to a filter that can run PHP. Then use the following snippet, which was shamelessly yanked from devel.module:

<?php/*
* 2008 Jun 26
*
* The code submitted by dharmanerd in his comment probably
* works better than the original I had, so I've modified this
* to match his code.
*
* The original code for this was shamelessly yanked from
* `devel.module`; it was the function `devel_cache_clear()`.
*
*/

// only allow site administrators to visit this page:if (!user_access('administer site configuration')) {
  drupal_not_found();
}
else {
  drupal_clear_css_cache();
  $tables = array(
    'cache',
    'cache_content',
    'cache_filter',
    'cache_menu',
    'cache_page',
    'cache_views',
  );
  foreach ($tables as $table) {
    cache_clear_all('*', $table, TRUE);
  }
  drupal_set_message('Cache cleared.');
  drupal_goto();
}?>

Set a URL path for this page (perhaps 'cache_clear') so that you can clear the cache easily. Clear the cache by visiting the URL or add the path to a menu link(watch your permissions).
Code Notes:

• The drupal_goto at the end of the page will redirect you to either the destination or to the main page of your site; you can change this if you wish.
• If this code is in a block that was visible on all pages (i.e. including the home page) then the home page would endlessly redirect to itself, breaking your site. The answer is to remove the drupal_goto() from the code, then all caches would be cleared on every page view.
• Because of the drupal_goto, you can never actually visit this page; you can edit it through the admin/content/node page.
• You may have to remove the path parameter to the function call drupal_goto, because it gets added to the homepage URL.
• If you missed some part of the code, which makes the site inaccessible you can remove the code through phpmyadmin, by browsing the block table and editing the appropriate block you created.

API reference

Welcome to the Drupal 6 developer's documentation. Newcomers to Drupal development should read the conceptual information provided in the "Components of Drupal" section, and then proceed to examine one of the heavily-documented example modules below. The examples are fully-functioning Drupal modules, so you can download them from the contributions repository and alter them as you experiment.

• Components of Drupal
  • Module system (Drupal hooks)
  • Database abstraction layer
  • Menu system
  • Form generation
  • File upload system
  • Search system
  • Node access system
  • Theme system
  • Constants
  • Global variables
• Example modules
• In-depth discussions
  • Form API Quickstart Guide
  • Form API Reference
  • JavaScript in Drupal 5 and Drupal 6

Read More....

11 Things About Drupal 7

(1) The default administrative theme is greatly improved.
In earlier versions of Drupal, the default administrative theme was a bit homely and hard for new, non-technical users to navigate.  There were a series of contributed modules for Drupal 6 you could install to improve the situation, but it was an extra step you had to take, and additional moving parts you have to deal with when updating.  Drupal now has a slick and user friendly administrative theme as part of core.  The administrative interface now includes Ajax goodness, an overall admin toolbar, shortcuts and generally increased loading times.
(2) Improved support for WYSWYG’s. 
In Drupal 6 you could enable WYSWYG functionality by installing external modules, but they never seemed to work quite right.  Drupal 7 makes the integration of WYSWYG editors more seamless.  The end result is that they work better.
(3) Drupal 7 loads faster.
A long time complaint about Drupal is that it makes a lot of database calls, causing high server load that lead to speed issues when serving un-cached pages.  Drupal 6 was a big improvement, but Drupal 7 features significantly less SQL queries causing sites to load faster.
(4) CCK is now part of core Drupal.
When working with Drupal 6, installing the Content Construction Kit (CCK) module was pretty much a requirement.  CCK has been moved into core and rebranded as the Field API.  Moving CCK into core gives developers the power to add fields to not only content types, but also to People, Taxonomy, etc.
(5) The image/file upload feature that is included in the Field API is invaluable.
Uploading files along with content in Drupal 6 was always a bit of a clunky process.  Getting it to function the way you wanted was always a battle.  In Drupal 7 what you can do right out of the box is much improved:

• The Field API allows you to specify which file types you want to allow (JPG, GIF, PDF, DOC, etc.).  It also lets you set upload limits and maximum dimensions when uploading images.  
• Files are now uploaded via an AJAX interface.  After the file is uploaded it is immediately displayed in the form, where the user sees the file name and can delete the file right there.  Further, as the file is uploaded the user sees a loading image so they can be confident that the file is getting loaded.

The end result is more flexibility for developers, and a better experience for administrators.  All of this was possible in Drupal 6, but it was a battle to get to the functionality you wanted.  The fact that these features are now integrated into the Field API will save developers a lot of headaches.
(6) There is more flexibility in what kind of content can be a custom content type.
In Drupal 6, content types were really designed to be text fields, with the Body field required for all custom content types you created.  In Drupal 7, this requirement has been removed.  This makes it less clunky to create non-text based custom content types for assets such as PDFs or images.
(7) Working with jQuery plugins is much easier in Drupal 7.
jQuery is probably the most popular JavaScript library, and allows for the rapid development of client side site features.     Drupal 7 has made it much easier in general to use jQuery in your themes, and also ships with a  jQuery 1.4.4, which  is much faster and more feature rich than jQuery 1.2.6, which was the default in Drupal 6.   For the front-end developers out there, this is a big improvement that will save lots of time.
(8) Drupal 7 uses PHP Data Objects (PDOs), which allows for developers to more easily write portable code.
By making this switch, Drupal 7 is no longer dependent on any specific type of database.  The result is greater flexibility.
(9) There are a lot more hooks, which allow for more customizations on a deeper level.
Hooks are what allow for the modules you write for Drupal to connect to Drupal core.  In Drupal 7, there are a lot more hooks and they have separated hooks that were used for multiple tasks into smaller pieces.  This makes Drupal 7 truly modular, and gives developers the ability to create deeper customizations.
(10) Drupal 7 is much easier to update.
Keeping Drupal 6 current was a hassle, as to update a module you had to download it, unpack it, upload it again and then run the update.  Drupal 7 features an Update manager that tells you when a module is out of date and allows you to update it right from the web interface.  Much, much easier, and more like the experience in WordPress.
(11) Blocks are much easier to configure.
In Drupal 6, to create a block you have to first create a block on the page you want it to appear, and then go to the slow-loading block overview page to set where on the page you want it to appear.  In Drupal 7 this is all done in one step.  While it sounds trivial, this can save a lot of time on more complicated sites.