How can I show that a control is in a pressed or selected state?

Treat it as a persistent two-state toggle, not merely a button with a click effect. Give it a visible on/off appearance and expose the same state programmatically with aria-pressed="true" when on and aria-pressed="false" when off. The WAI-ARIA Authoring Practices Guide recommends this pressed-state pattern for toggle buttons and says to update the state after activation. Keep the accessible label stable while using aria-pressed; for example, use “Save to favorites” in both states. [S1]

A focus outline or brief click effect can still show where someone is interacting, but it does not indicate that the feature remains on. Make the persistent appearance distinct—for example, a filled button for on and an unfilled button for off, if that suits your design. The guidance specifies the state semantics, not a required visual design. [S1]

That can be a command whose label describes the action available next, rather than a toggle button with a stable label. In the WAI-ARIA Authoring Practices Guide’s example, a label-changing command such as “Mute” becoming “Unmute” does not need aria-pressed. [S1]

Choose the model that matches the control: either keep a stable label and communicate the persistent state with aria-pressed, or change the label to describe the next action. Make the behavior understandable so people do not have to guess whether the text or a state indicator explains what is happening.

Not automatically. Use the state that fits the kind of control instead of applying aria-pressed to every item that looks selected. For example, the WAI-ARIA Authoring Practices Guide describes a combobox popup where the currently indicated suggestion can be exposed as selected, while the input still represents its entered value. That does not mean the combobox’s value has changed. [S2]

That example is specific to combobox popups, not a universal rule for every list, menu, or selection control. Identify what the selected appearance means: a persistent choice, the current suggestion being navigated, or only the item under focus. Then use semantics appropriate to that control and keep its displayed value and state consistent.

Here is a small stable-label toggle. The click handler changes the pressed state and the visible treatment from the same value:

<button type="button" id="favorite" aria-pressed="false">Save to favorites</button>
<style>
  #favorite[aria-pressed="true"] { background: #333; color: white; }
  #favorite[aria-pressed="false"] { background: white; color: #333; }
</style>
<script>
  const button = document.querySelector('#favorite');
  button.addEventListener('click', () => {
    const isPressed = button.getAttribute('aria-pressed') === 'true';
    button.setAttribute('aria-pressed', String(!isPressed));
  });
</script>

The example uses the pressed attribute to drive the visible on/off styling, so both reflect the same state. The particular colors are only an illustration; choose a treatment that makes the states clear in your design.

Check it by activating the button once: it should look on and expose aria-pressed="true". Activate it again: it should look off and expose aria-pressed="false". Also confirm that keyboard focus has a visible treatment of its own, so focus is not mistaken for persistent state. If another action can change the state, check that path too. Keep the label stable for this pattern; use a different state model for a changing-label command or another widget. [S1]