E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 3 (In chronological order)

From: Mike -
Date: Thu, Feb 27 2014 6:33PM
Subject: WCAG 2.0 Question: Converting Form to Static Version
No previous message | Next message →

Hello,

We would like to convert a PDF form into a static XHTML document. Part of the PDF has fillable checkboxes. In order for the XHTML document to satisfy WCAG 2.0, can decorative images be used to represent the checkboxes?

I am referring to the approach at: http://jsfiddle.net/WLQqf/. In the example, the items are presented as an unordered list. CSS is used to change the default properties of the list; namely a checkbox image (with null alt text) replaces the standard bullets.

While a static XHTML form will never be equal to a fillable PDF from a usability standpoint, does presenting the checkboxes in this fashion satisfy WCAG 2.0 (AA)? Or does a static version of virtually any form rule out the possibility of it being compliant?

Form fields often have intricate relationships with their surrounding text, and have to be given names, roles, labels, etc. so that screen readers can correctly associate those connections.

Thanks

From: Hewitt,Susan (DSHS)
Date: Fri, Feb 28 2014 6:24AM
Subject: Re: WCAG 2.0 Question: Converting Form to Static Version
← Previous message | Next message →

A "static" HTML form is not a form. If all that can be done is print it out and fill it in, it's become nothing but a web page. Is this what you mean by static? That it won't be able to be filled out and submitted online?

If this is your plan, I would not use native form elements such as labels, input types, etc. All this will do is confuse the screen reader user into thinking they're working with an actual form when they aren't. They're only working with a text page that's been designed to visually look like a form.

The example you shared isn't a form so it's not really an issue of meeting form standards by using images for bullets. Maybe someone else will say since what you're creating will visually look like one, you should use form elements in the markup but I really do think this would do a disservice to the screen reader user.

I'm not sure why you need to convert your true, interactive PDF form into a static HTML page. But if it's not possible to make an actual HTML form I would suggest keeping your PDF, making sure it's accessible, and putting it up alongside the static HTML page. This will give your users who are visually impaired true access to it. This is certainly the opposite of what people typically to do, though.

From: Mike -
Date: Tue, Mar 04 2014 6:42AM
Subject: Re: WCAG 2.0 Question: Converting Form to Static Version
← Previous message | No next message

Hi Susan,

My responses can be found below:

"Is this what you mean by static?"

When I say the form is "static", I mean that it is unchanging - it can't be completed or submitted online. There are no fields for the user to select or input their information. You can think of it as a text-only version of the form, with some checkbox images that are used to mimic the appearance/decoration of an actual form.

"I would not use native form elements such as labels, input types, etc. All this will do is confuse the screen reader user into thinking they're working with an actual form when they aren't. "

I wasn't suggesting that we assign form properties to non-form content. This would be improper use of these elements/attributes, and it would also render the page invalid at W3C.

"The example you shared isn't a form so it's not really an issue of meeting form standards by using images for bullets."

Agreed.

"If it's not possible to make an actual HTML form I would suggest keeping your PDF, making sure it's accessible, and putting it up alongside the static HTML page."

Agreed.

Any other thoughts/comments are always welcome.

Thanks again.


> From: = EMAIL ADDRESS REMOVED =
> To: = EMAIL ADDRESS REMOVED =
> Date: Fri, 28 Feb 2014 13:24:55 +0000
> Subject: Re: [WebAIM] WCAG 2.0 Question: Converting Form to Static Version
>
> A "static" HTML form is not a form. If all that can be done is print it out and fill it in, it's become nothing but a web page. Is this what you mean by static? That it won't be able to be filled out and submitted online?
>
> If this is your plan, I would not use native form elements such as labels, input types, etc. All this will do is confuse the screen reader user into thinking they're working with an actual form when they aren't. They're only working with a text page that's been designed to visually look like a form.
>
> The example you shared isn't a form so it's not really an issue of meeting form standards by using images for bullets. Maybe someone else will say since what you're creating will visually look like one, you should use form elements in the markup but I really do think this would do a disservice to the screen reader user.
>
> I'm not sure why you need to convert your true, interactive PDF form into a static HTML page. But if it's not possible to make an actual HTML form I would suggest keeping your PDF, making sure it's accessible, and putting it up alongside the static HTML page. This will give your users who are visually impaired true access to it. This is certainly the opposite of what people typically to do, though.
>
>