Changes to Some Extended Profile Input Types in BP 2.6.0

For BuddyPress 2.6.0, the core team worked to improve the structure of several extended profile input field types to improve the accessibility of the fields and also make them easier for developers to style. The field types that have been updated are checkboxes, radio buttons, and date boxes.

All three types have been restructured as <fieldset>s with the label for the field residing in the field set’s <legend>.

Checkboxes and radio buttons options have been wrapped in a new <div> with the class input-options and either checkbox-options or radio-button-options. Additionally, the labels for the individual options have been given the class option-label. These changes taken together should make it much easier to target option labels to apply styling. (Goodbye .selector > label + label to catch option labels!)

Date boxes have similarly gained a wrapper <div> with the classes input-options and datebox-selects around the three selects.

Here are some examples of how the code output for these fields has changed:

<!-- Checkbox inputs, before changes -->
<div class="editfield field_2 field_core-makeup optional-field visibility-public alt field_type_checkbox">
  <div class="checkbox">
    <label for="field_2">Core makeup</label>
    <label for="field_11_0"><input name="field_2[]" id="field_11_0" value="Goat" type="checkbox">Goat</label>
    <label for="field_12_1"><input name="field_2[]" id="field_12_1" value="Rhinoceros" type="checkbox">Rhinoceros</label>
    <label for="field_13_2"><input name="field_2[]" id="field_13_2" value="Slow Loris" type="checkbox">Slow Loris</label>
  </div>
</div>

<!-- Checkbox inputs, after changes -->
<div class="editfield field_2 field_core-makeup optional-field visibility-public alt field_type_checkbox">  
  <fieldset class="checkbox">
    <legend>Core makeup</legend>
    <div id="field_2" class="input-options checkbox-options">
      <label for="field_11_0" class="option-label"><input name="field_2[]" id="field_11_0" value="Goat" type="checkbox">Goat</label>
      <label for="field_12_1" class="option-label"><input name="field_2[]" id="field_12_1" value="Rhinoceros" type="checkbox">Rhinoceros</label>
      <label for="field_13_2" class="option-label"><input name="field_2[]" id="field_13_2" value="Slow Loris" type="checkbox">Slow Loris</label>
    </div>
  </fieldset>
</div>

<!-- Radio button inputs, before changes -->
<div class="editfield field_6 field_home-turf optional-field visibility-public field_type_radio">
  <div class="radio">
    <label for="field_6">Home turf</label>
    <div id="field_6">
      <label for="option_7"><input name="field_6" id="option_7" value="Honali" type="radio">Honali</label>
      <label for="option_8"><input name="field_6" id="option_8" value="Fantastica" type="radio">Fantastica</label>
      <label for="option_9"><input name="field_6" id="option_9" value="Toledo" type="radio">Toledo</label>
    </div>
  </div>
</div>

<!-- Radio button inputs, after changes -->
<div class="editfield field_6 field_home-turf optional-field visibility-public field_type_radio">
  <fieldset class="radio">
    <legend>Home turf</legend>
    <div id="field_6" class="input-options radio-button-options">
      <label for="option_7" class="option-label"><input name="field_6" id="option_7" value="Honali" type="radio">Honali</label>
      <label for="option_8" class="option-label"><input name="field_6" id="option_8" value="Fantastica" type="radio">Fantastica</label>
      <label for="option_9" class="option-label"><input name="field_6" id="option_9" value="Toledo" type="radio">Toledo</label>
    </div>      
  </fieldset>
</div>

<!-- Date box inputs, before changes -->
<div class="editfield field_10 field_birth-date optional-field visibility-public alt field_type_datebox">
  <div class="datebox">
    <label for="field_10_day">Birth date</label>
      
    <label for="field_10_day" class="bp-screen-reader-text">Select day</label>
    <select id="field_10_day" name="field_10_day">
      ...Day options...
    </select>

    <label for="field_10_month" class="bp-screen-reader-text">Select month</label>
    <select id="field_10_month" name="field_10_month">
      ...Month options...
    </select>

    <label for="field_10_year" class="bp-screen-reader-text">Select year</label>
    <select id="field_10_year" name="field_10_year">
      ...Year options...    
    </select>
  </div>
</div>

<!-- Date box inputs, after changes -->
<div class="editfield field_10 field_birth-date optional-field visibility-public alt field_type_datebox">
  <fieldset class="datebox">
    <legend>Birth date</legend>

    <div class="input-options datebox-selects">
      <label for="field_10_day" class="bp-screen-reader-text">Select day</label>
      <select id="field_10_day" name="field_10_day">
        ...Day options...
      </select>

      <label for="field_10_month" class="bp-screen-reader-text">Select month</label>
      <select id="field_10_month" name="field_10_month">
        ...Month options...
      </select>

      <label for="field_10_year" class="bp-screen-reader-text">Select year</label>
      <select id="field_10_year" name="field_10_year">
        ...Year options...
      </select>
    </div>
  </fieldset>
</div>

These changes represent a continued effort to update and improve BP templates and the markup they use. In this case we’ve aimed for improved accessibility by structuring our form markup using meaningful groupings of semantic elements and homogenized rendering across browsers and devices. If you have styled the above-mentioned form controls, please review your styles and make the necessary changes, if any.

Read more about these changes at #7083 and #6678.

#6678, #7083

Dev Chat Summary for March 16, 2016

Last week’s meeting focused on reviewing trac tickets slated for BP 2.6.0 which already had patches uploaded.

Activity link moderation doesn’t output useful error message to end users (#6719) @rayisme requested feedback on custom error handling for the activity stream using WP_Error. “Would love it if @hnla could test the patch in 6719 and see if that addresses the points in #6822″

Suspension of BP comment moderation functionality (#6822) @rayisme wrote about removing the activity moderation feature entirely.

Simplify CSS targeting of radio and checkbox label fields (#6678) @dcavins thanked all for the feedback in trac to change markup to use fieldsets/legends for some profile fields in the front end.
Action: Patch changing the markup has been committed to trunk during the meeting.

Avoid using HTML tags in translation strings (#6898 through #6911) @djpaulgibbs had some concerns about whether the proposed changes would make the strings harder to translate and asked @boonebgorges for his opinion on the tickets.
Update: Boone has committed most of the patches to trunk.

Accessibility: Bump headings in template files (#6875 through #6882) @djpaulgibbs, @hnla, @rayisme, and @mercime had a long discussion about the merits and challenges of updating template files to meet accessibility guidelines. There were concerns that changing them (headings) might cause angst to developers needing to make the changes to established themes and regular users will be posting in our forums. There was a proposal to roll the accessibility updates in a new bp-template pack. @rayisme added, “Let’s roll with the accessibility changes and be ultra-aggressive with the heading styling so bp-legacy CSS rules take precedence.”  @mercime commented that committing the updates early in the 2.6 dev cycle will allow ~ 3 months for developers to update themes.  Accessible BP templates are the way to go forward. @djpaulgibbs: “We need to do these. We also need to get the companion stylesheets updated for these changes (if/as necessary). Let’s post on bpdevel once the changes are in. We can contact the major BP theme builders in advance. ”
Action: First batch of new heading updates have been committed to trunk after the meeting.

Slack log: https://wordpress.slack.com/archives/buddypress/p1458158441000061

#6678, #6719, #6875, #6882, #6898, #6911, #dev-chat