The Australian Government coat of Arms

Communities of practice

Communities of practice

Buttons


#1

Please provide any feedback for the Buttons component.

You can also view the component page on our documentation site for the Buttons component.


#2

I’m :face_with_raised_eyebrow:'ing about rendering links as buttons to “catch users attention”. That was the rationale used to endorse marquee and blink. I’m not opposed to rendering links as buttons just as I’m not opposed to rendering a two-state radio button group as a toggle switch, but imagine how this could be abused and discourage that.


#3

I think you’re right; we’ve had the button-vs-link thing come up a few times so we should adjust the phrasing in the documentation to be more about UX/task-flow. I’ve just now opened a git-issue so that we can address the docs, thanks for the feedback @NathanaelC.

I’ve also written a long explanation over on github which is maybe worth adding to the covo and our documentation. But it comes down to this basic example


#4

I just published a new major version of buttons. This change affects users using the react component as a link. The property href has been removed and replaced with link. You also have the ability to inject a component as the linkComponent. This allows easier integration with react router.


#5

Just seeking peoples thoughts or if they have any research on the links / buttons and why they are underlined.

We have taken the DTA tool kit and have been modifying based on our visual designers preference. One of the things that I’m disappointed about is that for territory links / button have had the underline removed. I have suggested that this lacks affordance as all users especially those with a visual impairment may not be able to perceive the link / button.

The link / button colour with the rest of the text on the page is lower than the 3:1 ratio and to make matters worse when the user hovers over, the curser changes as does the background colour by a ration of about 1.03:1.

Although the links / buttons are not necessarily in blocks of text. I still believe that they should visually stand out with my preference to follow the DTA approach and underline.

Any feedback / support you can be provide would be much appreciated.

Thanks


#6

Hi @rossstep welcome to the community! I am just going to jump in and try to answer your questions.

Any research on the links / buttons and why they are underlined.

Buttons have underline on hover to address WCAG 2.0 criterian 1.4.1. ( Color is not used as the only visual means of conveying information ). As this question has been asked a few times it is documented under the rationale section for the buttons.

You can see examples of why the underline is needed when going to the accessibility section of buttons. If you hover on the greyscale example the main change you notice is the underline.

We have taken the DTA tool kit and have been modifying based on our visual designers preference.

That is really awesome, I would love to see the end result!

…I’m disappointed about is that for territory links / button have had the underline removed

I discuss above the reasons why we remove the underline. I personally sat through multiple iterations of these buttons and our team is always looking to improve them, do you have any suggestions on how we can have three different button styles that still convey meaning on hover without using colour?

The link / button colour with the rest of the text on the page is lower than the 3:1 ratio and to make matters worse when the user hovers over, the curser changes as does the background colour by a ration of about 1.03:1.

I am not too sure what you mean by this one? The colour contrast of our buttons and the text inside them meets the colour contrast ratio. Do you have an example of it not meeting the ratio? Action colour on background is 6.15, dark action on dark background is 4.53.


#7

Hi Alex,

Thanks for your quick reply

I’m aware of WCAG 1.4.1 and I’m advocating for underlines on for territory links / buttons.

In this case, I’m talking about a button that looks like a link and is not underlined on initial state.

I’m also pushing an accessibility rather than a WCAG point of view (focus on the human side not the criteria).

The argument that I receive for not doing it (this is because they don’t want to do it), is that the success criteria states surrounding text and specifically say block of text (G183).

So a link/button at the bottom of the page would not meet that criteria. I know that the success criteria are not exhaustive and my interpretation based on ever accessibility meeting I’ve been to aligns with the DTA.

I was more hoping that you would have specific research that could be shared to support the claim.

For button and links, that look like buttons, when hovered over they have also removed the underline. The rational is that a user can rely on the curser. I know from reading the working group notes on 1.4.11 that users with visual impairment liked having another visual queue rather than the curser as that can be missed. Peoples eyes are not always looking were the curser is e.g they could be looking at the start of the sentence, while the curser could be at the end.

I was just looking for support as I’m one person within a team of twenty. Many of them that have come from design studios in the private sector.

Thanks
Ross


#8

No problems! I am a little confused by your reply so sorry for all the questions!

I’m aware of WCAG 1.4.1 and I’m advocating for underlines on for territory links / buttons.

Do you mean tertiary buttons when used as a link or a button?

In this case, I’m talking about a button that looks like a link and is not underlined on initial state.

I am not really following this one. The tertiary button style is underlined on initial state, have you potentially changed its appearance?

Maybe a screenshot or example of the problem you are facing would help. I would not recommend using tertiary buttons without primary or secondary buttons near them. That is an antipattern I am happy to add that as additional documentation.

I’m also pushing an accessibility rather than a WCAG point of view (focus on the human side not the criteria)

Thats great, our team is always happy to make changes that better the human experience. We strive to balance this with WCAG 2.1 if possible.

The argument that I receive for not doing it (this is because they don’t want to do it), is that the success criteria states surrounding text and specifically say block of text (G183).

So a link/button at the bottom of the page would not meet that criteria. I know that the success criteria are not exhaustive and my interpretation based on ever accessibility meeting I’ve been to aligns with the DTA.

I am not sure what you are not doing? Are you talking about not using a tertiary button?

This criterion is talking about a block of text, not a button. It could be that the buttons are being used incorrectly. I am happy to update our guidance on when to use the button pattern if that is the case.

We are currently working on templates to better explain how to use the components in the context of a page. I hope this will help your situation in the near future.

I was more hoping that you would have specific research that could be shared to support the claim.

Unfortunately I do not have any research to share, our team is open in the way we approach solving problems and iterate quickly based on the feedback agencies give us when using the patterns.

This pattern has been thoroughly tested and used across multiple Australian Government websites, we have not heard any specific problems. We are always looking for new insights if you have any to share.

For button and links, that look like buttons, when hovered over they have also removed the underline. The rational is that a user can rely on the curser. I know from reading the working group notes on 1.4.11 that users with visual impairment liked having another visual queue rather than the curser as that can be missed. Peoples eyes are not always looking were the curser is e.g they could be looking at the start of the sentence, while the curser could be at the end.

This is why our buttons change the underline on hover. The change in appearance helps the user identify that the link or button has been hovered on. Is there anything we are not doing or could do better?

I was just looking for support as I’m one person within a team of twenty. Many of them that have come from design studios in the private sector.

I feel that, always happy to organise a time to talk with your team and try and resolve any problems they may be having. This community is open and I would love to see them join in and get involved.


#9

Hi Alex,

Sorry for any confusion.

I’m supportive of the DTA approach, I have concerns about our approach.

The attached screenshot are taken from our design system. They have been modified from the DTA.

I’ve attached screen shots of the default and tertiary buttons.

![ter|690x177]

In the screen shot, there is no affordance to indicate that the buttons are actually buttons.

The tertiary button has a contrast 1.58:1 with the standard black text on the website. So even relying on colour (which would not be my preference) still isn’t sufficient.

When hovering over the actions, there is a subtle background change, but no underline.

Thanks for your assistance.

Ross


#10

I’ve attached the second screenshot as I can only attach one at a time.


#11

Hi @rossstep thanks for the screenshots it really helps understand the problem you are having.

Some quick points on the the button pattern your team has created from an accessibility and usability perspective:

  • Links in body text should have an underline to stand out more from the text in the page. The same pattern should be followed with tertiary buttons.
  • The background colour for the default button style is non existent and adds no benefit to the user.

I really see the way your team is approaching building the buttons highlight some problems I have been thinking about. When using the system you have a few ways of using it:

Customise the system

This is the recommended approach as it gives you the most benefits as you get the code, design, rationale, guidance, accessibility, research and testing.

We have put a lot of effort into making the design system extremely flexible and we have documentation explaining how to customise the colour scheme and components. I would highly recommend anyone using the design system to follow this guidance or reach out to our team so we can support you on your journey.

We are still trying to improve this with some upcoming features. If you have any recommendations, concerns or questions on how to customise the system please let us know.

Learn from the system

This is usually taken by teams who use different technology stacks, or want to fill in gaps in components quickly. They benefit from the code, design and research however they have to usability test, write rationale and do their own accessibility testing.

They try to match the code and design, customising the colours to meet their users need.

Teams building in this way are better suited to contribute back to the system as they are using the best practices from it.

Create your own system

This is what I see your team is doing. They have probably been inspired by the Australian Government Design System and want to create something new as the system has something they are missing.

When you go down this path you are creating a new design system. Your design, code and functionality will be different. This will cause more work in writing guidance, doing usability testing and getting the components in front of real users. This causes duplication of work and creates more inconsistencies across the APS causing a poorer user experience for citizens.

The work done, will not scale as you do not benefit from the work of multiple agencies. You will no longer benefit from the community we are trying so hard to create. Delivery will be slower instead of using existing components you will have to create your own and fix issues in isolation. As new components and technologies emerge you will need to consider refactoring your code.


As it looks like your team has decided to create a new Design System, what benefits are you trying to get or getting from the Australian Government Design System?


#12

Thanks Alex, you have summed things up extremely well.

We do have a different technology stack as we are relying on angular. However, I don’t see a need to change the look and feel from what the DTA have implemented (with the exception of theming/branding and this has been catered for in the design system).

Once again, thanks for taking the time to respond.


#13

No problems, as I said above if you need any help or guidance please reach out!