xprofile field "description" placement inconsistency

[sbrajesh]

In BuddyPress 2.9, The field description was moved inside the field class( A bad choice as it forced all themes to show the description twice and caused a huge headache).

The problem with current implementation is that for some of the field types the description is shown before the form element and for some after the form element.
Here is a list to show where is shown:-

Checkbox:- after the legend, before the checkbox
Datebox:- after the legend, before the datebox
Multi select box:- After the multi select box
Number:- After the number input box
Radio:- After the legend, before the field.
Selectbox:- After the select element
Texarea:- After the textarea
Textbox:- after the textbox
url:- after the url

There are many issues with the current implementation.

1. You have taken the control out of theme author and put it into the hands of the plugin developers.
2. It will lead to inconsistency as some put it before the element and some after the actual elements.

3. The goal should be to give more flexibility and provide a consistent user interface, how do we achieve that with the current implementation.

4. Even BuddyPress's own implementation is inconsistent, how do you expect others to have any consistency.

Please let me know what are my options if I want to show the description consistently. Also, do not suggest javascript as a mean to achieve what should have been a normal thing.

[mercime]

Hi @sbrajesh. I'm sorry that the accessibility and usability improvements done in #7348 to the xProfile Fields has caused you some headaches :(

Close proximity of the descriptions to the respective form fields is necessary to provide logical connections of related form elements for sighted users as well as those using assistive technologies (ATs).

ATs read the source code of each page in a linear fashion, from top to bottom. Before #7348, this is what was read in generic terms for a radio field group with an opened profile visibility settings:

Which adjective describes you best? grouping list
List of 3 items
bullet, Funny, radio button unchecked
bullet, Thoughful, radio button unchecked
bullet, Happy-go-lucky, radio button unchecked
End of list
Clear link
Change button expanded
Who is allowed to see this field? grouping list
List of 4 items
bullet, Everyone, radio button checked
bullet, Only Me, radio button unchecked
bullet, All Members, radio button unchecked
bullet, My Friends, radio button unchecked
End of list
Close button
Description of the first radio button group

Some users can become confused about whether the description is about the profile visibility preference (when enabled) and if not, why the description is so far away from the profile field. Screen reader users who tab through the interface won't even hear/touch/know that there's a description associated with the form field.

#7348 makes the interface more accessible for everyone. For one, moving the descriptions right before/after the profile fields improved on the connection between description and form field for sighted, keyboard and/or AT users. Along with some more improvements in said ticket, here's how that radio field group is read now:

Which adjective describes you best? grouping 
Description of this radio button group
Funny, radio button unchecked
Thoughtful, radio button unchecked
Happy-go-lucky, radio button unchecked
Clear link
Change button expanded
Who is allowed to see this field? grouping
Everyone, radio button checked
Only Me, radio button unchecked
All Members, radio button unchecked
My Friends, radio button unchecked
Close button

It's cleaner and clearer. Note that there are numerous ATs with different versions and settings out there, compatible at different levels with different browsers at different configurations and serving different needs for different users. For example, some ATs won't read lists as list items (bullet) if list-style:none, but some do all the time. Another example is that some ATs would read the description as Paragraph, Description of radio button group while some don't read paragraph before the words out loud. There are so many permutations that we just do the best we can to get it right with semantic elements and improved UI or fix accessibility issues for other ATs as they are reported or uncovered.

Re inconsistencies: Following are the logical and accessible patterns for the positioning of the descriptions for the different form fields.

1. Profile fields with single form controls like text, number, and url input types along with textarea, select box and multi select box=> descriptions are placed immediately after respective form controls. All single form controls are associated with descriptions via the visual proximity of the description to the form control for sighted users and aria-describedby attributes added for ATs.
2. Profile fields with multiple form controls like the radio buttons, checkboxes, and dateboxes=> descriptions with tabindex="0" are placed immediately before the form controls to improve discoverability by sighted, keyboard, and AT users so that they have the necessary information before going through the multiple form controls of respective fields.

Thanks for bringing this up. I hope that I've clarified the description locations for you. It's all about improving accessibility for everyone.

[sbrajesh]

Hi @mercime
My apologies for the delayed reply.
Thank you for clarifying. Obviously you have more experience with the web accessibility/assistive technologies, so I believe that it was all in good intention.

Still, Can you please point me to any recommendation about the single/multi fields like you have explained in the last paragraph.

I don't have much understanding of the accessibility/assitive technologies yet(I do plan to read them soon) but I have been looking at the WebIM and WAI sites and could not find anything. All I could find was "aria-describedby" as on this page.
​https://webaim.org/techniques/forms/advanced

My concern is that the current implementation makes the form visually inconsistent. I am all in favour of supporting ATs but loosing the consistency for normal users can't be the right option.

Still, if it needs to be this way, can you please make a post on bpdevel blog and let plugin developers know about the above 2 recommendations to avoid further inconsistencies by them.

Thank you

[mercime]

Replying to sbrajesh:

Hi @mercime
My apologies for the delayed reply.
Thank you for clarifying. Obviously you have more experience with the web accessibility/assistive technologies, so I believe that it was all in good intention.

No worries @sbrajesh. My turn to apologize for this late reply. Been out of town on business and didn't bring this dev laptop with me.

Still, Can you please point me to any recommendation about the single/multi fields like you have explained in the last paragraph.
I don't have much understanding of the accessibility/assitive technologies yet(I do plan to read them soon) but I have been looking at the WebIM and WAI sites and could not find anything. All I could find was "aria-describedby" as on this page.
​https://webaim.org/techniques/forms/advanced

Sure thing. The descriptions for single form controls are all placed immediately after the respective single form controls, very common as you can see on the webaim.org page you referred to.

Following are some examples of the correct placement of the descriptions for fieldsets with multiple field controls:

Date inputs: from the U.S. Web Design Standards, an official website of the United States government, the description is placed above the date inputs ​in this screen. The form controls' labels like month, day, and year are shown, not hidden for screen readers like BP dateboxes are. In addition, each form control has the aria-describedby attribute pointing to the description above it. Ticket to follow.

Checkboxes and radio buttons: Examples for the correct placement of descriptions are available from the WordPress Accessibility Team's Github Repo showing the ​recommended a11y changes for a new Settings API v2 or more likely, Field Settings API. At the top of that page, you'll find that the team moved the description for checkboxes for the "Default Article Settings fieldset" from below the checkboxes (where it is now in wp-admin) to after the legend and immediately before the checkboxes. The radio buttons fieldset for "Default Avatar" near the bottom of the same page has the description in the same spot as we have it now in wp-admin, i.e., immediately before the radio buttons.

My concern is that the current implementation makes the form visually inconsistent. I am all in favour of supporting ATs but loosing the consistency for normal users can't be the right option.

I will beg to disagree with you on this. All users benefit from seeing/hearing/knowing the descriptions/additional instructions before they start reading through their selections, specially when you have lots of checkboxes/radio buttons to choose from like the Default Avatars fieldset you've seen earlier.

Still, if it needs to be this way, can you please make a post on bpdevel blog and let plugin developers know about the above 2 recommendations to avoid further inconsistencies by them.
Thank you

Thanks @sbrajesh. Will do. I've already planned a series re BP Accessibility which includes the improvements mentioned above.

[mercime]

Date inputs - U.S. Web Design Standards