0

I have a question regarding SC 1.4.4 Resize Text for Placeholders for inputs. I am not for the design we currently have, but have to work a solution with whatever design I have.

The first row in the table has inputs to filter text in the table. In normal view without zoom, the complete placeholder text is visible. But when we zoom to 200%, the placeholder just shows "Filter" and the remaining text is cut off. My first question is whether this violates 1.4.4?

If so, the solution I recommended is to provide a title attribute for the input field, which is not ideal. It only satisfies people with low vision who can use a mouse to hover. But, users with motor disabilities using keyboard will still not be able to see, even though they can visually see the table and relate the column name with the input.

Is there a better way to address this issue without changing the designs? Attaching a screenshot for your reference.

Table without zoom

Table with Zoom

1

You have a few options here. Here are 3 I can think of:-

Option 1. just use CSS media queries.

When you zoom a browser the way it calculates the media query break points is based on CSS pixels. So when you zoom a 1920px wide screen 200% it actually works out breakpoints based on 960px (960px * 200% = 1920px).

So an easy solution is to just look at your media queries and see if the site is usable at all screen sizes, if it isn't then an alternative layout for smaller screens would be advised. Either stack the inputs on top of each other or show the inputs after pressing a button.

Option 2 - redesign the HTML

Also you could just add the word "filters" above the inputs and remove the need for "filter by" as part of the visible text, which make it fit.

Side note: While we are on the topic of accessibility, only having placeholder text is not very accessible. I wrote a long answer on whether just having placeholder text technically passes WCAG, but technicalities aside I would advise against having placeholder text as the only identifier on an input.

For people with cognitive impairments that affect memory, or anxiety based impairments it can be frustrating / unsettling that the field label disappears, causing them to delete text in a field to check they have entered it in the right place.

As such I would have a permanently visible label above the input.

Combining the two principles (visible label and grouping the items so they all fall into the category of "filters") could also be a way to tackle the issue.

For screen reader users you can then associate the inputs with the "filter by" text using aria-labelledby. For other users the association should be clear based on the proximity of the "filter by" text if you lay things out correctly.

Sample HTML

<h2 id="filters-heading">Filter By</h2><!--or an appropriate heading level or just text -->
<tr class="row-filters-container">
    <td>
        <label>
            <span id="label-input1">Some column</span>
            <!--adding 2 IDs to `aria-labelledby` means they will be read in order in a screen reader.-->
            <input aria-labelledby="filters-heading label-input1">
        </label>
    </td>
    <td>
        <label>
            <span id="label-input2">Some other column</span>
            <!--adding 2 IDs to `aria-labelledby` means they will be read in order in a screen reader.-->
            <input aria-labelledby="filters-heading label-input2">
        </label>
    </td>
[...etc rest of table filters]
</tr>

Option 3 - Accessible tooltips

Instead of using title, which as you pointed out is not very accessible for keyboard users (and users on touch devices), you can create your own tooltips that show on focus as well as hover.

The principles within this jsfiddle for tooltips that appear on focus as well as hover could easily be adapted to apply to inputs.

The solution in that fiddle might be a little overkill for your needs (as it falls back if JavaScript is not enabled) but the idea of a focus activated tooltip is simple enough.

Obviously this has the a similar issue to using a placeholder, in that it only shows when the field is focused or hovered, but it is still a better solution and might help you out if you can't make the other options work.

The beauty is you can make a much larger label with additional information (such as suggested input format) if you want so there are pros and cons.

What would I do?

Well I would probably go for all 3!

Make the inputs larger on smaller screens by adjusting layout (as then long user input is visible as the inputs are larger).

Add visible labels and or a heading.

Add a tooltip on focus and hover with detailed instructions (due to the space constraints of table filters).

That way the whole thing will not only be accessible but super easy to use for everybody!

Finally I aw aware I didn't actually answer whether this passes 1.4.4 but as placeholder text is not advised I would just say that if you add labels and they do not work at 200% size then that would be a fail, placeholders....its very grey from a "compliance" perspective. From a user perspective it is a big thumbs down not being able to read the input text and that should be more important!

1
  • 1
    Sorry for the late response, but I thought about Option 1 and 3. Option 2 which you provided is not going to work out since design team is going to get mad if we make or add any changes :) But, we went with using option 3 on adding tooltips to the input fields. The only challenge was that we didn't want to show it on normal resolution. So we had to use media queries to show the component only on 200% zoom. But your insights always helps. – Ramji Seetharaman Apr 19 at 22:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.