The Australian Government coat of Arms

Communities of practice



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;


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


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 UIKIT 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 (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.


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:


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.


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?