The Australian Government coat of Arms

Communities of practice

Communities of practice

Core

Please provide any feedback for the Core component.

You can also view the component page on our documentation site for the Core component, which includes things like colour, typography, and spacing.

I wanted to use AU-fontgrid( 18px ); however it only takes values from inside the AU-fontsizemap. The AU-fontgrid function should be able to support pixel values.

@include AU-fontgrid( 18px ); // using default 1.5

fontsize: 18px;
fontsize: 1.125rem;
lineheight: 1.555;
1 Like

I can see why it might be nice for the function to behave this way but it seems to contradict the purpose of the type-scale, which is consistency across components for easier sharing.

For example you might want 21px which isn’t in the system, so that component is now harder to share with other teams and maintain a consistent look.

One idea might be that I enter the size i want ( 21px ) and the output is the closest value in the type-scale ( md ) but I feel this would seem like an unpredictable output and probably cause confusion.

We’ve also made the list of fontsizes (fontzise-map) overridable (!default) if teams have unique requirements. See here

1 Like

Default font-size = 16px might be too small

We’ve recently just had feedback from an internal team here that the default body font-size of 1rem | 16px is quite small on mobile. Has anyone using the system run into similar feedback?

When we were designing the Design System we had a similar thought; but at the time it felt like it would add far too much complexity to the system to have the sizes (md, lg, etc) change value at different device sizes, which might also make the AU-fontgrid function feel pretty unpredictable.

The downside is that the nicer, more legible, typography online these days is larger than 16px, see Medium (18px mobile, 21px desktop) or Gov.uk (16px mobile, 19px desktop) or ATO (18px)

As far as I see it, the best outcome would be to change the typescale on mobile (we use ~1.25) so that your biggest headings aren’t too big on a small device. The tradeoff though is system complexity.

I’d been keen to hear people’s thoughts on this.

We have definitely had that feedback from mobile users, so much that we have a “responsive type” epic in our backlog.

We have also heard some of the same thing on desktop particularly in older demographics. We considered just raising the font size just on pages for that audience, but we had similar consistency concerns.

2 Likes

Thanks for the feedback Podgkin. Given the fact that it’s in Core and we have a number of teams with this feedback and looking into it, it should be something worth resolving in the system. – when it’s closer to coming up on either your backlog or ours (currently an ‘enhancement’ on ours) lets share our thinking / code solutions here for open discussion. :+1:

1 Like

Just wondering, but on pages for that audience, couldn’t you include some sort of increase and decrease font size button off in the top right or something?

We have thought about it, and it is in our backlog to look at, but we haven’t worked out all the details. Our current thinking is to copy what the Norwegian government does with its text resize button. They don’t increase the text size, they just detect your OS and browser and tell you how to increase the size yourself.

This is basically taking the approach of teaching them to fish, so that they aren’t reliant on specific websites to put in text resizing.

2 Likes

Hi, I’m trying to find the documentation for links within content. The Documentation site doesn’t seem to specifically define this and there are a couple of different practices used throughout, some of which on first viewing are counter-intuitive.

For instance, some links are coloured text with underline and onRollover the line disappears (providing visual affordance of activation), yet in other places the colour of the link disappears onRollover and looks like it is no longer active since it is the same colour as the rest of the text in the paragraph!

Also I’ve noticed that link underlines shown at default state in some heading examples actually increase cognitive load since the reader looses the descender shape indication elements that help speed up word pattern and structure recognition when parsing meaning and intent.

Am I missing something in current cognitive research?

Hi @stephenwho we don’t provide documentation for each minor html element unfortunately. The code for the links in content would be contained in the body component.

We have changed some of the link states for some components. Some times there are other visual indicators that indicate the element itself is clickable and the underline causes an increased cognitive load like you identified above with the headers.

We are always trying to iterate to give the best user experience, I empathise with the header links and can see exactly what you are talking about. Do you have any ideas how to make a header look like an interactive element without the increased cognitive load?

1 Like

I would like to discuss the idea with everyone about the current colour conversion functionality.

I think that the way we currently adjust inaccessible colours is a bit invasive and can confused both designers and developers alike. Currently, a developer would enter a colour value and if that colour doesn’t meet WCAG colour contrast standards, the closest accessible colour will be returned. This new colour could then cascade other colours to change as the core library tries to find an accessible palette.

I propose that we trial removing this functionality but leave a warning to let the developer know that the colour isn’t accessible. I see nice niche use cases where a team must use a certain colour palette or at the very least, it could make using the design system feel harder to use. For example, if I enter #008490 for my darkAction colour, the background will adjust accordingly.

An alternative to this suggestion might just be to documented what we already do a bit better but it doesn’t sit well with me that we force change inputted colours.

1 Like

Definitely like the idea of warning a developer rather than forcing a colour change, particularly if the function returns colour that is vastly different and unexpected, for example. Naturally this is where further documentation can help.

When we’re building program websites at my agency, sometimes colour schemes have already been set and agreed upon (say between a business area and communications teams, or business and MO) prior to digital designers/developers. So I wouldn’t say it’s uncommon to be forced to use a particular colour palette. In these instances, personally I’d like the tool to suggest a11y action a different text or action colour which would hopefully be less of a change than a background, but :man_shrugging:

1 Like