[buddypress-trac] [BuddyPress Trac] #7613: xprofile field "description" placement inconsistency

[buddypress-trac]

#7613: xprofile field "description" placement inconsistency
------------------------------+----------------------
 Reporter:  sbrajesh          |       Owner:
     Type:  defect (bug)      |      Status:  closed
 Priority:  normal            |   Milestone:
Component:  Extended Profile  |     Version:  2.9.0
 Severity:  normal            |  Resolution:  wontfix
 Keywords:                    |
------------------------------+----------------------
Changes (by mercime):

 * status:  new => closed
 * resolution:   => wontfix
 * severity:  major => normal
 * milestone:  Awaiting Review =>


Comment:

 Replying to [comment:2 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 [https://standards.usa.gov/components/form-controls/#date-input 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 [https://wpaccessibility.github.io/test-forms/options-
 discussion.html 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 of post re BP
 Accessibility which includes the improvements mentioned above.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7613#comment:3>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac