Closed thyhmdo closed 9 months ago
Within the CTA
component in Carbon for Dotcom, we pull in the link with icon and pre-populate the following options:
Storybook link
Outside of local, anchor, and external, the above have been requested from adopters to utilize in various pages.
Related: #3869
Moving forward with new updates but there are two Unresolved issues after discussing this with @mbgower and the Design team:
1. Visited vs Unvisited link Michael thinks that WCAG lacks clear guidance on distinguishing between visited and unvisited links, which they see as a failure in addressing the use of color to convey information. He submitted a pull request (PR) last summer to address this issue, but it seems that the proposed change has not been incorporated into the guidance yet. They provide a link to the merged but unpublished change that they had suggested. https://github.com/w3c/wcag/pull/3222/files
---> We may want to keep this the same in the guidance as an option until there's an update on their side
2. Underline or no underlines for all links This seems like an issue to enforce the default links on products. We spotted the inconsistency of how Links are often used with Ghost buttons and it's hard to distinguish them when they appear closely on the same page or at the same position.
On the Accessibility side, It’s possible to distinguish links by colour, if the contrast is strong enough by G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them. For dangers of a colour-only approach, see the failure technique F73: Failure of Success Criterion 1.4.1 due to creating links that are not visually evident without color vision
---> We will need to add an underline for the focus state but probably leave the default Standalone link as they are at the moment.
Ref discussion: https://github.com/carbon-design-system/carbon/discussions/15175 Ref boxnote: Usage tab pdf
Usage tab
[x] Description: Possibly reword this sentence if needed to describe different use cases. Should we cover those here? Are we covering all of them currently?
[x] Overview section: When not to use: Reword this paragraph to be more clear. Gower has commented on this in his PDF.
[x] Anatomy section: In image: Change "Learn more" to something like "View docs".
[x] Content:
Clarify that we
recommend
labels accurately reflect the content users will find at the link destination. This may not always be possible."For further content guidance, see IBM Accessibility on link purpose." Revise this to link to the Accessibility tab for more information
[x] Interactions section: Remove Screen reader parts.
[x] Standalone link section:
Change sentence to this "Standalone links are the default link style for Carbon and only have an underline on hover and focus states."
Change the image to have different link content. For example, say something like "View docs" with a right arrow icon.
[x] Visited style section: Is it an accessibility violation to not use visited link styles? If you are not using visited styles, is there a known accessibility consideration that could be put in place? Ask Gower.
[x] Add somewhere what our stance is on not allowing full images as pure links, but that it is okay to have an image within a card + text as a link, etc.
Answered questions from a11y discussion
Is a link made up of text + icon really a link, or is it a button? A link is a link, not a button, regardless if it is just text or text + icon. We need to be clearer about the content we use as examples in our react storybook and website guidance to establish this.
In-page anchor links are violating the guidance for link color and icon placement. The anchor links on the Carbon website are coming from Gatsby, not our core components. That being said, we should at least provide an underline on hover and focus in Gatsby. This will be a separate issue.
What about links that are just images? We do not recommend using pure images as links. We have seen use cases of having cards that also include blocks on content within the container below the image treated as a link. We can add more about this in our guidance.