- summary rationale followed by links to relevant best practices and standards

CommentFileSizeAuthor
#3 accessible-369477-1.patch6.74 KBkat3_drx

Comments

johnbarclay’s picture

Title: Add references to standards and best practices in adming interface » Add references to standards and best practices in admin interface
Version: » 6.x-1.x-dev

Add references to standards and best practices in admin interface

kat3_drx’s picture

Assigned: Unassigned » kat3_drx

I'll take this on, using the WCAG 2.0 guidelines.

kat3_drx’s picture

StatusFileSize
new6.74 KB

Here's the first patch, very straightforward and simple. I'm throwing it up for review just to make sure the approach is solid and tips are understandable. Separate links apply for guidelines and individual techniques for meeting criteria associated with content, navigation, and (if the proper modules are implemented) forms, and time-based media. I think there are probably more/better ways to extend where the module-specific tips appear but figured it would be best to offer it up for testing first.

johnbarclay’s picture

This is great. I'll test and apply it.

We might store the references as an array or heredoc or a separate user conf file for easier editing and allow for the lists and links to be themeable. But that sort of stuff can wait until we have enough content. We may also want the site admins to select the standards they want to show up in the users help info. I suppose with the help hook there is a desire to keep the amount of code being processed to a minimum.

johnbarclay’s picture

Status: Active » Needs review

Got this in the last patch. Sorry for the delay, I ended up restructuring the data. It should be easier to add more contexts and contextual help now. The contexts are just defined like kat3 did originally:

  if((($arg[2] == 'webform') || ($arg[3] == 'components')) && ($arg[1] != 'content')) {
    return accessible_api_helpset('webforms');
  }
  
  if($arg[2] == 'swftools') {
    return accessible_api_helpset('audio_and_video');
  }

The actual contexts to tips mapping are in another file:

$accessibility_data['contexts'] = array(
  'webforms' => array(
    'title' => 'Accessibility Tips for Web Forms',
    'tips' => array('fieldset_and_legend','optgroup')
  ),
  'audio_and_video' => array(
    'title' => 'Accessibility Tips for Audio and Video',
    'tips' => array('transcript','transcript2','volume'),
  ),
  'content' => array(
    'title' => 'Accessibility Tips for Content Writing',
    'tips' =>  array('content_writing','summary','scope','header','color','descriptive_headings_and_labels'),
  ),
  'blocks_and_menus' => array(
    'title' => 'Accessibility Tips for Content Writing',
    'tips' => array('skip_repitition','skip_nav','nav_to_content','headings', 'structured_links','develop_patterns'),
  ),
);

Then the tips are in the same file:

$accessibility_data['tips']['fieldset_and_legend'] = array(
    'type' => 'wcag',
    'text' => 'Use the "fieldset" and "legend" attributes to add a description of groupings of form controls
    (<a href="http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html"
    title="guidelines 1.3.1">guidelines 1.3.1</a> | <a href="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H71"
    title="technique for 1.3.1">technique 1.3.1 H71</a>)'                            
    );


$accessibility_data['tips']['optgroup'] = array(
    'type' => 'wcag',
    'text' => 'In a "select" dropdown, use "optgroup" to group the "option" elements
    (<a href="http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H85" title="technique for 1.3.1">technique 1.3.1 H85</a>)'                      
    );

So basically it behaves as your patch did, but the data is structured differently. I'll add future patches quicker as I have a better CVS setup now.

johnbarclay’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
johnbarclay’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Assigned: kat3_drx » johnbarclay
Category: feature » bug
Status: Needs review » Needs work

I think I broke this again in 7.x-2.x.