User tests: Successful: Unsuccessful:
This fixes a very big a11y issue.
In all list views we start the row with a check box. This check box has no label which is not good AND when using assistive technology such as a screen reader it will only indicate the word "select". It doesn't indicate what you are selecting. As the title (the item you are selecting) is several steps away from the select box you are stuck with a select with no meaning.
Now a screenreader will see this chick box as "Select '%ArticleName%"
reference for the a11y technique used http://www.coolfields.co.uk/2011/04/accessible-forms-should-every-input-have-a-label/
Also adds scope=col to the table headers and scope =row to the article name
The checkall in the theader is not a header but a cell so it is changed to a td (will need some styling ut thats beyond the scope)
{if accepted I will update all the other components}
This is fully backwards compatible
If there is documentation how to use grid then it will need updating to provide info about the new optional param
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_content Libraries |
Labels |
Added:
?
|
as stated this will need styling and that is beyond the scope of this pr
it would be great of the a11y team tested this as it solves a big accessibility problem. if accepted then this can be applied to all the list views and we can move on to other areas of improving accessibility
Is it possible to place the label after the checkbox-input tag?
For programming (styling) and for accessibility reasons
it is recommended to be after
In the link you provided
http://www.coolfields.co.uk/2011/04/accessible-forms-should-every-input-have-a-label/
But also here
https://www.w3.org/WAI/tutorials/forms/labels/
they show / recommend for checkboxes, radios to be after the checkbox-input tag
I tested it successfull with NVDA, but...
@brianteeman: Is it possible to mark a second cell in the first row as the column header? Is there any reason why you cannot mark this cell as a column header?
@ggppdk : The order of the label in the code is not important for the screen reader. It can be placed in front of and behind the control. It is important that it is connected to the control.
@zwiastunsw
ok,
so if placing it after does not make difference / problem to the screen reader,
lets care also about the other benefit that i mentioned
Sorry but what benefits?
@zwiastunsw do you mean the check all cell? If so then it should not be marked as a column header. This check all is not a header it is an individual cell. I don't have the source reference to hand but it's the correct thing to do. The alternative is to have a cell header BUT/AND move the check all to a place outside the table structure
Ok. I understand.
I have tested this item
I have tested this item
I was talking about the general recommendation (both of links given above) that when adding a label at same level as an input-checkbox, then it is best placed after the input, probably in this context it is not so much needed as this change is meant for screen readers only
After applying the PR the reported accessibility problems for the record selection checkboxes are gone
That recommendation doesn't apply here as we are using "label for". Because some screenreaders will automatically associate text after the checkbox even if there is no "label for" you can get away without the "label for" if the text is afterwards but it is best practice to have it this way
There is now a small code style error reported in drone.
codestyle should be fixed now - just waiting for drone to complete
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-07-17 07:15:10 |
Closed_By | ⇒ | laoneo |
You guys do great work with all these accessibility changes!
Now to apply this to all the other lists
Some styling differences. Title is bold. White background for Title column when checked all.
Before PR:


After PR: