Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad/incomplete example for Understanding 3.3.2 #755

Open
patrickhlauke opened this issue May 23, 2019 · 13 comments
Open

Bad/incomplete example for Understanding 3.3.2 #755

patrickhlauke opened this issue May 23, 2019 · 13 comments
Assignees
Labels

Comments

@patrickhlauke
Copy link
Member

@patrickhlauke patrickhlauke commented May 23, 2019

In https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html the last example:

A U.S. phone number separates the area code, exchange, and number into three fields. Parentheses surround the area code field, and a dash separates the exchange and number fields. While the punctuation provides visual clues to those familiar with the U.S. telephone number format, the punctuation is not sufficient to label the fields. The single "Phone number" label also cannot label all three fields. To address this, the three fields are grouped in a fieldset with the legend "Phone number". Visual labels for the fields (beyond the punctuation) cannot be provided in the design, so invisible labels are provided with the "title" attribute to each of the three fields. The value of this attribute for the three fields are, respectively, "Area Code", "Exchange", and "Number".

as the title attribute won't show for keyboard users, it's not really a good example...should the example be removed, or at least generalised to say that a tooltip is shown when the field is hovered or focused (leaving it up to the reader to work out how it's done, i.e. as a custom-built tooltip not just title) ?

@awkawk

This comment has been minimized.

Copy link
Member

@awkawk awkawk commented May 23, 2019

I don't think that the tooltip content is required to be keyboard accessible in this case. The visual information present is sufficient to allow a sighted user to know what to input. The title (or aria-label) is primarily for the AT user.

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

@patrickhlauke patrickhlauke commented May 23, 2019

So a mouse user can see that the three fields are "Area Code", "Exchange", "Number". AT user can hear that the three fields are "Area Code", "Exchange", "Number". But a sighted keyboard user has to know/guess this?

@awkawk

This comment has been minimized.

Copy link
Member

@awkawk awkawk commented May 23, 2019

A sighted user gets their context from the visual information (3 separate fields, punctuation, knowing the structure of phone numbers). This would pass if aria-label was used instead of title, right?

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

@patrickhlauke patrickhlauke commented May 23, 2019

i'd say no, it wouldn't either? borderline, but this example seems rather tainted in any case if we're having such discussions here as well... (incidentally, as a non-US person, that split is not necessarily obvious to me, for instance)

@awkawk

This comment has been minimized.

Copy link
Member

@awkawk awkawk commented May 23, 2019

I do think that it would pass using aria-label. Which SC would it fail? As a non-US person "area code", "exchange", and "number" probably don't provide great clarity. For that matter, I suspect that most US people wouldn't typically use "exchange" so the visual information is the most important.

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

@patrickhlauke patrickhlauke commented May 23, 2019

Which SC would it fail?

3.3.2?

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

@patrickhlauke patrickhlauke commented May 23, 2019

turning this around: why would you think it passes 3.3.2? are there labels/instructions provided about what the user is meant to enter into the three separate inputs? are the parentheses and dash here supposed to be sufficiently clear? or does it not just rely on assumed knowledge on the part of the user, without making it explicitly clear what the three inputs are meant to represent?

(and yes, this is only a minor thing...but i'm more worried about the potential implication here that devs may take away that a title is just enough, when clearly for keyboard users it isn't; same way that just using aria-label may well be cool for AT users, but then leaves out any non-AT users as well)

@awkawk

This comment has been minimized.

Copy link
Member

@awkawk awkawk commented May 23, 2019

A form that is looking for a phone number that breaks it into three controls with an overall label of "phone number" is sufficiently labeled for sighted users to know what to do. The individual controls still need an accessible name since the visual labelling isn't apparent to visually impaired users.

If I go to a different country I'm more likely to make a mistake whether I am sighted or not because I'm not familiar with the conventions.

@patrickhlauke

This comment has been minimized.

Copy link
Member Author

@patrickhlauke patrickhlauke commented May 23, 2019

is sufficiently labeled for sighted users to know what to do

and i guess this is the crux of our disagreement...

If I go to a different country I'm more likely to make a mistake whether I am sighted or not because I'm not familiar with the conventions.

...but isn't the point of 3.3.2 to fight exactly this problem? am confused by the cavalier attitude here, i must admit.

but ok, assuming you're right then...why suggest title here at all? if this example is only meant to fix it for AT users / to provide an accessible name, it should be an example for 4.1.2 not 3.3.2.

in short...let's remove this example as it seems rather edge-casey and confusing/mixing different concerns (or expand it as i said, to make it clear that we're talking about a tooltip rather than title per se)

@awkawk

This comment has been minimized.

Copy link
Member

@awkawk awkawk commented May 23, 2019

and i guess this is the crux of our disagreement...

OK. Others can weigh in.

...but isn't the point of 3.3.2 to fight exactly this problem? am confused by the cavalier attitude here, i must admit.

There's no cavalier attitude, we're just talking about what is required. If you want to advocate for what is BEST then that's ok, but that's different.

but ok, assuming you're right then...why suggest title here at all? if this example is only meant to fix it for AT users / to provide an accessible name, it should be an example for 4.1.2 not 3.3.2.

Becasue when this technique was made aria didn't exist.

in short...let's remove this example as it seems rather edge-casey and confusing/mixing different concerns (or expand it as i said, to make it clear that we're talking about a tooltip rather than title per se)

I don't regard this as a very high priority. You are welcome to suggest specific changes, but there are many more pressing items for the WG to review.

@goetsu

This comment has been minimized.

Copy link

@goetsu goetsu commented May 28, 2019

Regarding current situation, my understanding is as title is currently listed as sufficient technique the current example is compliant. The problem of having it not displayed on focus was at the time more seen as an UAAG problem.

But then we have a more wider problem to know if WG even consider to have label (and not only instructions) visible only on focus as a compliant solution regarding 3.3.2 I would say yes based on my interpretation but others seem to disagree. Then depending on WG answer the understand and associated techniques may need to be clarified on this.

@mraccess77

This comment has been minimized.

Copy link
Contributor

@mraccess77 mraccess77 commented May 28, 2019

Generally I would fail form fields that only have labels on focus, however, in other situations I've seen use of color issues that are addressed when an item is focus -- for example a chart with a legend that uses color when the corresponding legend is highlighted when the item in the chart is focused. So I agree there isn't clear guidance on this topic.

@patrickhlauke patrickhlauke self-assigned this Jan 7, 2020
@frex65

This comment has been minimized.

Copy link

@frex65 frex65 commented Jan 7, 2020

Thinking about a different scenario where there are three text fields for entering a date. is the format DD/MM/YYYY or MM/DD/YYYY? If this information is only available via the “title” attribute, mouse and screen reader users are covered but there is a lot of scope for sighted keyboard users to get it wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.