ARIA-Group: a viable alternative for Fieldset / Legend?

Share on FacebookShare on LinkedInShare on Twitter

Development Newsletter Sign-up Button

ARIA’s role=”group” and role=“radiogroup” can be used to group form controls to yield results that are comparable to HTML’s FIELDSET – LEGEND elements. Testing shows that when these roles are set on container elements (like div, td, etc.) and labeled with other ARIA attributes like aria-labelledby or aria-label, the method offers a viable alternative to that is supported by browsers like Firefox and Internet Explorer and screen reading software JAWS for Windows and NVDA.

Note: My testing was done using Firefox 11, IE9, IE 8, JAWS 13, JAWS 12 and NVDA 2011.2.

The FIELDSET element by default draws a border around the form controls it holds. HTML does this deliberately as an accessibility feature for users who need such a visual cue. Some developers suppress this border via CSS or avoid using the fieldset-legend elements when it”obstructs” visual design, for instance, when a form is within a table. ARIA’s role=group / radiogroup does not create a border; yet it offers developers the ability to convey grouping of related form controls via markup and any visual styling mechanism of their choosing (color, font, border or any other) when they find the fieldset-legend inconvenient in some situations.

Here is a sample file created for this test. While the main objective was to test out role=group / radiogroup and compare it against fieldset-legend, I also reviewed latest support a few other ARIA attributes and the HTML 5 “required” attribute and have documented the observations as part of this exercise.

Description of the sample file:

The file contains 3 forms: a search form, a partial registration form and a partial credit card application form.

  1. Two landmarks, role=search and role=main are used; the latter has an aria-label=”registration form”. (The main section contains 2 forms; aria-label text is merely illustrative).
  2. The registration form has identical sets of fields for first and second applicants. The fields for first applicant are grouped using fieldset/legend method; role=group is used for the fields under second applicant.
  3. Role=group is used for SSN fields and date of birth fields within the form controls under each applicant.
  4. A fieldset-legend is used for gender radio buttons for the first applicant; role=radiogroup is used for gender radio buttons for second applicant.
  5. The HTML 5 “required” attribute and aria-required=true have been used on name and date of birth fields. The SSN fields use only the ARIA method. The gender radio buttons for the first applicant relies on the legend element (asterisk) and uses aria-required for the second applicant’s gender radio buttons. Except for the gender buttons within a fieldset, an asterisk is alsoplaced next to every field to convey that it is required input; but the asterisk is deliberately not programatically associated with the form controls.
  6. The Credit card application is within a layout table with role=presentation.
  7. The credit card type radio buttons are grouped using role=radiogroup.
  8. All group and radiogroup roles are labeled with aria-labelledby.
  9. The search field and the 3 parts of SSN fields use the title attribute to label the fields; explicit label association using for-id method is used for the rest.
  10. The visible instructional text for date of birth placed at the end of the registration form is linked with the The DOB fields use aria-describedby to associate the tip about date format. The tip is visible text near the end of the registration form.

Note: The sample file does not use any presentation styles to demarcate groups of form controls.

Summary of Observations

Accessibility Feature NVDA 2011.2 with Firefox 11 NVDA 2011.2 with IE 9 / IE 8 JAWS 13 / 12 with Firefox 11 JAWS 13 / 12 with IE 9 / IE 8
Fieldset/Legend Legend announced for first field with word “grouping” as suffix Legend announced for first field with word “grouping” as suffix Legend announced for first field [$]Legend announced for every field till next group / fieldset-legend/radiogroup encountered. (Note: JAWS 12 failed to announce legend text; instead read the aria-label “Registration form” set on landmark role=main).
Group (or radiogroup) with label (i.e. aria-label or aria-labelledby Group’s label announced for first field with word “grouping” as suffix Group’s label announced for first field with word “grouping” as suffix Group’s label announced for first field. JAWS also announces “Group starts” and “Group ends” in browse mode. Group label announced for every field till next group / fieldset-legend / radiogroup encountered. JAWS also announces “Group starts” and “Group ends” in browse mode.
Upon main Group / Fieldset change [*] When group changes, correctly announces main group label or legend while tabbing forward or backward along with nested group-label When group changes, correctly announces main group label or legend while tabbing forward or backward along with nested group-label When group changes, correctly announces main group label or legend while tabbing forward or backward along with nested group-label Only announces immediately associated group label/legend while tabbing forward / backward. So does not announce main group label / legend when the main group changes while tabbing backward.
Visual rendering: Fieldset element v/s role=group (user agent feature; does not impact screen reader users but other users e.g. cognitively impaired or learning impaired ) Fieldset has a default border; group has none Fieldset has a default border; group has none Fieldset has a default border; group has none Fieldset has a default border; group has none
HTML5 Required attribute Announced as ‘invalid entry’ when field is unfilled. Can co-exist with aria-required=true Not announced Announced as ‘invalid entry’ when field is unfilled. Can co-exist with aria-required=true Not announced
aria-required=true / false Announced as ‘”required” when attribute is set to “true”. Nothing otherwise. (Note: Even “yes” value works) Announced as ‘”required” when attribute is set to “true”. Nothing otherwise. Announced as ‘”required” when attribute is set to “true”. Nothing otherwise. (Note: Even “yes” value works) Announced as ‘”required” when attribute is set to “true”. Nothing otherwise.
aria-describedby attribute Associated text announced Associated text announced Associated text announced Associated text announced
Landmark navigation role (e.g. main, search, navigation) with an aria-label Announces “main landmark” Announces “main landmark” Announces aria-label followed by “main region start”. At end announces “main region end”. Announces aria-label followed by “main region start”. At end announces “main region end”.
Landmark role: Upon navigating to first form field in main region in forms mode [*] Does not say ‘landmark’ or role or aria-label. Only announces text associated with label. Only announces aria-label set on div (with role=main) that contains the form, in addition to text associated with label. [$] Announces aria-label text plus “main landmark region” for first field, in addition to text associated with label. (Note: JAWS 12 fails to announce landmark role or its aria-label. Only announces text associated with field including legend). [$] Announces word “landmark region” only (not aria-label) in forms mode for every field till next group / radiogroup / fieldset-legend is encountered, in addition to text associated with label. (Note: Bug with JAWS 12 here. It announces aria-label for landmark role, does not say “main region” and fails to announce legend text.
Table with role=presentation Regarded as layout table; presence of table not announced in table navigation mode regardless of settings. Regarded as layout table; presence of table not announced in table navigation mode regardless of settings. Regarded as layout table; presence of table not announced in table navigation mode regardless of settings. Regarded as layout table; presence of table not announced in table navigation mode regardless of settings.

[*]: This is not an accessibility feature. Only intended to convey what a user experiences when group / section change is encountered and differences in user agent behavior.

[$]: This is a difference in behavior between JAWS 12 and JAWS 13.

Conclusion:

As one might expect there are nuances in behavior across browsers and screen readers tested. Yet:

  • The roles “group” and “radiogroup” are well supported and may be used to group form controls in situations where one might use HTML’s fieldset – legend elements. It is advisable to include some visual cue via CSS to convey grouping too.
  • The other ARIA attributes also are well supported: aria-label, aria-labelledby, aria-describedby, aria-required, role=”presentation”, and the landmark roles. (Note: I have not used aria-labelled by or aria-label to associate text labels (other than group labels) with form controls but have relied on the robust LABEL element and not so robust title attribute for this).

Created by Sailesh Panchang, Deque Systems | May 14, 2012

 

Development Newsletter Sign-up Button

6 comments

  • Brian Richwine Permalink

    Any idea how this works on VoiceOver or WindowEyes?

  • Jared Permalink

    The code in the example is so mangled that I would be very apprehensive to trust your results. There are missing spaces between attribute names, extra quotation marks, etc. which could be causing some of the attributes to not be accurately applied. I’d recommend validating the page and re-testing for accuracy.

  • Paul J. Adam Permalink

    Hi Sailesh, I tested this file with Voice Over on OS X Lion and on iOS 5.0.1. There was a strange issue where the first example using fieldset and legend did not work on OS X Lion, but when I removed the role=”main” attribute it worked correctly, reading the legend each time as you navigate by form controls.

    The second example where you used role=”group” and aria-labelled by worked great, just like a normal fieldset/legend setup. The second, aria only, example worked fine whether the role=”main” was present or not.

    On iOS none of the examples worked, legend is not read and neither is the group’s aria-labelled by. I also tested some other basic fieldset legend examples like the webaim screen reader survey and legends are not read when navigating radio/checkbox groups by form controls on iOS.

    So iOS behavior is similar to Window Eyes. There were many WE users complaining that the webaim survey was not accessible because the questions were not announced, this is because like iOS 5.0.1 window eyes is not supporting the fieldset legend correctly.

    Jared, I’ve cleaned up the validation errors from the original example, It’s located here: http://pauljadam.com/axtest/aria-group.htm

    My testing on both versions was the same on iOS and OS X so the validation issues did not change anything for Safari/VO and Mobile Safari/VO.

    Results for all the aria test cases worked very well on OS X Lion but did not on iOS 5.0.1.

    Strangely iOS calls all radio buttons checkboxes. aria-describedby for the date format does not work on iOS

    To fix the validation issues I had to change the role=radiogroup to role=group. It said I had to set elements inside a radio group to role=radio but then gave me more errors when I did that.

    This would all be so much easier if VoiceOver operated the same on OS X Lion and iOS!

    Brian, I’m not sure what ARIA support Window Eyes has.

  • Sailesh Permalink

    Hello Jared,

    Thanks. I have cleaned up the sample file and fixed those errors … a strayquote mark before end of input tag for 4 radio buttons etc.

    The W3C Validator does flag:

    - legend element cannot have an h2 in it, and

    - radiogroup must only have radio element in it. This second one is because of the span element with the red asterisk.

    Well the ‘look and feel’ of the file I understand is fine and I have let these violations be … especially h2 within legend to expose structure of the page (with consistent use of headings) and mainly to allow one to compare and contrast the use of fieldset-legend versus role=group: i.e. one can use role=group and an h tag as done for ‘Second Applicant’.

    Now too, the behavior of screen readers is no different from what is noted in the article.

    Replacing the h2 with a SPAN in the legend (as Paul’s example file demonstrates) does not change the behavior noted in the article.

    With Window-Eyes:

    - one has to turn on the option to announce fieldset / legend.

    - it does not read group or radiogroup labels

    - it does announce aria-required and HTML ‘required’ attribute.

    Thanks Brian and Paul for your comments.

    Sailesh

  • Brian Richwine Permalink

    Thanks for the updated info on Window Eyes and Voice Over. I’m only now learning how to use Voice Over and don’t feel proficient enough to trust my results. I work in higher education and it used to be all of our screen-reading software users used JAWS, however many are using Voice Over now.

  • Devarshi Pant Permalink

    Sailesh,

    Thought I would share these results:

    Test with IE 9 / NVDA / Win 7:

    > The landmark roles of search, main, and content info are shown by the utility list (element list). Depending on how a user accesses the form field though, there could be variations in speech output, for instance, on tabbing into the form field ‘Name,’ under first application, NVDA announces “registration form grouping first applicant grouping first applicant name required,” but when using the quick key ‘f’ NVDA says “main landmark name edit required.” Apparently, aria-label = “registration form” under the first applicant as suggested in the post has something to do with this variability – which I think is a non-issue.

    > Social Security and Gender labels under both applicants are announced as ‘Social Security, grouping’ and ‘Gender, grouping.’

    > The required field attribute in the Gender radio button (first Applicant) is not voiced. It does however announce the same for the second applicant.

    > The required attributes within Name, Date of Birth, and Social Security fields are consistently voiced under both applicants. The only exception occurs in the second applicant’s Date of Birth field, which associates the visible instructional text.

    Test with rotor (iOS and VoiceOver):

    > Three landmarks are present. It will not announce the name of the landmark but instead voice ‘landmark start’ and ‘landmark end’ based on where the VoiceOver cursor is – meaning a user probably would have to guess the landmark’s name / context based on current location.

    > Social Security and Gender labels under first and second applicants are not announced.

    > Credit card type radio group label is not announced.

    > Title attributes on the three Social Security text fields are announced.

    > aria-describedby on the date of birth field (second applicant) is not announced.

    > The required attribute on name and date of birth fields is announced.

    > The required attribute on Gender (First Applicant) is not announced.

    > The required attribute on Gender (Second Applicant) is announced. Interestingly VO announces Gender radio button controls as checkboxes.

    Thanks,

    Devarshi

Leave a Reply