Test whether Views' form fields are labeled

There were no errors thrown by WAVE. I double checked the form field labels to make sure they made sense.

I am not sure if there is a list of correct "field form labels" - if there is, please post and I will double check them.

I'm wondering which modals did you checked. Some potential problematic pages could be:

• add/edit a field/filter/sort/contextual filter/relationship
• reorder fields/filters ...

@XJM: yes, Yesterday I was thinking about a problem with the Views accessibility review: the Views UI is really complex and we should ensure that everything is tested and, if possible, that two people won't loose their time testing the same thing (at least until the accessibility review is completed).

So I was wondering what the best method to track progress about this review was... And I thought that:

1. We could create a wiki page (maybe on the accessibility group) to serve as a report on what needs to be done and what has been already done;
2. Or start a new issue for every bug found and edit the summary of this issue to let others know what has been tested

Any thoughts?

BTW, I plan to spend some time on this issue next weekend...

I ran most of the Views UI through the WAVE Toolbar and added issues to the Views.UI component in the issue queue:

#2044523: Page: Theming missing Label
#2044511: Label missing in Page: The title of this view & The menu path or URL of this view
#2044521: Label used for markup, not associated with input form

Not a label/form issue, but also #2044505: Remove empty headers in Views UI <h2 id="views-ajax-title"></h2>

I'm not certain that this would have caught them all, but certainly highlighted a few that have been missed.

A huge majority of these are covered by #933004: Test that all form elements have a #title for accessibility

Yup.. But there are going to be theming issues for those issues, as they don't want the title to appear.

As @tim.plunkett already said, most of these unlabeled fields have been labeled to make the form property validation API patch pass tests. So, let's postpone this issue on that one and, as soon as it gets in, let's review the Views UI and see if we've missed something.

@mgifford: I expect a lot of issues like "hide the label for this field" to appear in the cueue after the property validation API commit! :D

Agreed @falcon03 - this is a great time to find & fix up those remaining errors.

I just don't want this held up by that.

The property validation API has not been committed yet because there is some discussion going on about its implementation.

In the meantime, the missing #title we found out in drupal by working on that API have been committed in a separate issue: #2074509: Add missing #title property to ensure form accessibility.

We just need a quick review of the Views UI to see if there are leftover form fields without a label...

Updated issue summary.

@xjm is there a list of screens for the Views UI? I assume that there must be. Is it just this:

• A
• Title: Content - ERROR: Multiple Form Labels
• Format
• Format: Table | Settings
• Fields
• Content: Node operations bulk form
• Content: Title (Title)
• Content: Type (Content Type)
• (author) User: Name (Author)
• Content: Published status (Status)
• Content: Updated date (Updated)
• Content: Link to edit content [hidden]
• Content: Link to delete content [hidden]
• Content: Translation link [hidden]
• Global: Dropbutton (Operations) - ERROR: What is with the empty More SUMMARY text (edit-options-more)?
• Content: Has new content (Has new content)
• • Add fields
  • List additional actions
• Filter criteria
• Content: Published status or admin user
• Content: Published status (grouped) - ERROR: Missing label on radio button for <Any> in bottom table
• Content: Type (exposed)
• Content: Title (exposed)
• Content revision: Language (exposed)
• • Add filter criteria
  • List additional actions
• Sort criteria
• Page settings
• Path: /admin/content/node
• Menu: Tab: Content | Parent menu item
• Access: Permission | Access the Content overview page
• Header
• • Add header
• Footer
• • Add footer
• No results behavior
• Global: Unfiltered text (Global: Unfiltered text)
• • Add no results behavior
  • List additional actions
• Pager
• Use pager: Full | Paged, 50 items

A couple issues from the WAVE Toolbar, but generally pretty good.

What's the status of this issue?
As META #1802678: [META] Views: accessibility review is already closed.

Tagging Amsterdam2014

Is this really the only issue open blocking keeping #1805996: [META] Views in Drupal Core open? Can anyone provide a good update on what needs to be done in order for this to just be closed? (Perhaps I can help? ;-) )

I am removing the Novice tag from this issue because it is not clear whether this issue is still relevant in its current form. The original purpose appears to be a pre-requisite for including views in core.

I went through most of Views UI and found two new issues using http://wave.webaim.org/toolbar/

There's a lot in Views UI though so not 100% sure I got it all. With this (chrome or firefox) plugin installed though it is pretty trivial to quickly see that all labels on a page are associated with form elements.

More testing would be good though.

Testing current implementation of the Views UI to verify labels

Began manual testing during the Vienna 2017 sprint with WAVE extension in Chrome.

Views

Views listing page

admin/structure/views

Input field has '#title' set and is visually hidden.

Views settings page

admin/structure/views/settings
Page passes.

Advanced Views settings page

admin/structure/views/settings/advanced
Page passes.

Views UI

The Views UI administration interface has many possible input combinations, so I spot checked the modals but will need to continue testing in order to provide a comprehensive evaluation and update.

I did a survey of the filters at the top of various admin listings in core, before realising this issue existed, and filed #2942037: Admin list filter fields are inconsistently labelled.. These issues aren't exactly duplicates - the other one only looks at listing filters, but looks beyond views UI.

Regarding new labels becoming displayed as a result of #933004: Test that all form elements have a #title for accessibility, I've been hiding the new ones visually. Looks like that's what others have done also.