Accessibility opportunities


Hi there,  I see a couple of opportunities to improve the accessibility of TypeForm forms.  

  1. Allow users to adjust the color of placeholder text.   I haven’t found any templates that have placeholder text with sufficient contrast.  
  2. The new address fields have an accessible name that doesn’t match the visible name.  For example, the Address field has an accessible name of “Enter your street name and number”.  Users that use speech to text will not be able to access the Address or Address 2 fields.  See WCAG 2.5.3 Label in Name.   

 

I’d like to use TypeForm to request information from students, but I need to make sure it’s accessible.  Would you consider the above?


5 replies

Userlevel 7
Badge +5

Hi @kherr Thanks for stopping by and sharing this! I shared this with the product team, and they let me know: 

  • They’re not planning to work on changing the color of the place holder text because the placeholder text is not intended to be an accessible descriptor of the input of a field because it disappears as soon as the respondent starts entering text. Regarding accessible labels - programatically the labels and Ids match up correctly in the code, so the input for Address and Address line 2 are being correctly described by the labels. The address block is built to be generic so that it can take addresses in the multitude of formats in which they exist.
  • As for the second point, would you mind sharing an example of where you’re seeing the issue? 

Hi~  

 

The input field for address has an aria-label of “Enter your street name and number”.  (similarly, the Address 2 field has an aria-label.)This supercedes the id/for relationship and becomes the label for assistive technology. So, while you do have an id/for, it is not the computed accessible name.  See the accessible name computation.

 

Here’s the code block:

<div data-qa="block" class="Spacer-sc-__sc-1fl5ef-0 ejiLNy">

<div class="Spacer-sc-__sc-1fl5ef-0 emAogi">

<label for="3100c5ba-c384-4771-af2c-c737b85ab7c7" class="TextWrapper-sc-__sc-1f8vz90-0 kJxojX">Address</label>

</div>

<div class="InputWrapper-sc-__sc-26uh88-1 jqVhzK">

<input id="3100c5ba-c384-4771-af2c-c737b85ab7c7" type="text" autocomplete="name" maxlength="250" name="name" tabindex="0" aria-label="Enter your street name and number" aria-required="false" placeholder="65 Hansen Way" class="InputField-sc-__sc-26uh88-0 kZzNdQ" value="">

</div>

</div>

 

Regarding the placeholder text, I agree for most places.  The one place that stuck out to me is when you open the country drop-down for telephone number.  The word “search” is placeholder text and is acting as a label.  

 

Th

Userlevel 2
Badge

Hello @kherr 

I’m the manager of the team who looks after the Typeform form renderer. Thanks for reaching out to us about the opportunities to improve Typeform!

I’ve had a look at the address block and you’re right about the mismatch. Given that there are visible labels for each of the inputs the `aria-label` is actually being used incorrectly and we should remove this. I’ll double check with our developers and make sure I’m not jumping to conclusions here but we will look to getting this resolved.

Regarding the placeholder text - I’d agree that it might make sense for us to give control to our form Creators to customise this and for the telephone drop down it’s probably not the best use of placeholder but we do use other aria labels in place to help our non-sighted users... I suppose though for sighted users this is a bit of a pain. I’ll speak to our designer to see what improvements we can make here, I know we also use this pattern in our dropdown question. 

Thanks for the feedback!

 

Userlevel 2
Badge

@kherr Sorry for the delay in getting back to you. I wanted us to properly validate your concern with the address block. 

We’ve had a look at the relationship between labels, aria-labels as well as how the placeholders are also presented. We’re of the opinion that the approach we’re using is correct which and was validated by Fable our digital accessibility partner  when the address question type was released - To be clear this was tested on JAWS, VoiceOver, NVDA and TalkBack without any issues relating to labels and aria labels. 

Given your enquiry though, our engineers have revised the implementation and haven’t found any issues except that there can be quite a bit of cognitive load required to understand the block when reading out the whole thing so we’re going to look at this further, but I don’t have a timeline of when this will be.

Rest assured though, we work hard to meet and maintain a WCAG 2.1 AA standard and we’re always testing typeforms with assistive technology users to make sure that we maintain it. We try to reduce accessibility issues as much as possible, but we know we’re not perfect but and that sometimes issues might appear (as in any software development). If/when issues are found, we prioritise them and fix accordingly. The following Help Center article can help creators ensure their forms are accessible. 

 

Hi Stu.  Thanks for your response.   Fable is a great company, and I’m so glad to hear you’ve tested this with users with disabilities.  Are you saying that the Label in Name, WCAG 2.5.3 won’t be fixed?  

Reply