Accessibility with Matrix

(Anewport) #1

We are going through a long process of ensuring our website conform to the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA which is just a bundle of joy. As we are progressing we are noticing that some of the Matrix features produce content that doesn't conform.

 

For example using the %form_contents% keyword is great for our users, but the output of some of the form fields isn't, such as radio select groups which do not get <fieldset> or <legend> elements added. Using a Date/Time select field with default values set to blank doesn't apply the "selected" attributes but it does add the attributes if we populate this field. And the <form> as a whole is printed out within a <table>.

 

Also on the Calendar Page asset we can specify the width of the columns in px which used to be fine but now we are moving towards responsive designs and this doesn't work at all. Maybe having the option to choose px or % as the unit of measurement would be better but I know that tables are always going to be an issue with responsive as this time.

 

This thread isn't about me complaining but just want to raise the issues so they could be put on scope to be resolved in future releases and for others to list out what they have encountered or any solutions used in the short term. Thought this might be better than submitting a million bug/feature requests as I find them.

 

 

(Anthony Barnes) #2

Accessible forms have always been problematic. We have some internal feature requests already to give us potentially alternate default output from Matrix, but nothing yet available. When we implement accessible forms for clients the majority of the HTML is hand coded giving greater control, but meaning more work for those of us that set forms up regularly. We do of course have some streamlined processes on how we arrive at the customised HTML, but this doesn't involve anything that is produced by Matrix as a default.

(Nic Hubbard) #3

This thread isn't about me complaining but just want to raise the issues so they could be put on scope to be resolved in future releases and for others to list out what they have encountered or any solutions used in the short term. Thought this might be better than submitting a million bug/feature requests as I find them.

 

I do think though, that if you submit bugs for these that they will get fixed easier than posting it here. You can be more specific in the bug reports and they will get attended to right away.

(Anewport) #4

When we implement accessible forms for clients the majority of the HTML is hand coded giving greater control, but meaning more work for those of us that set forms up regularly.

I usually do the same - it takes longer like you said but I think the pay off is worth it.  

We do of course have some streamlined processes on how we arrive at the customised HTML, but this doesn't involve anything that is produced by Matrix as a default.

Care to share? A lot of our users aren't that HTML savvy so maybe we should look at an easier way for them to produce forms.
 

I do think though, that if you submit bugs for these that they will get fixed easier than posting it here. You can be more specific in the bug reports and they will get attended to right away.

I think I might do that too. Just interested if anyone has come across anything else that may be problematic.