Meter
UI pattern
meter role, an accessible name that says what it measures, and a current value within its range.A meter shows a measurement within a known range, such as disk usage, battery charge, signal strength, or how closely a search result matches a query. It reports a current value between a minimum and a maximum, and it can show whether that value counts as low, high, or close to ideal.
A meter is read-only. Users watch its value but can't set it, so it isn't in the tab order and has no keyboard or pointer behavior of its own. When activating a meter is meant to reveal more detail, as on a dashboard, that action belongs to a separate control placed beside the meter.
There are two ways to build one. The native HTML <meter> element carries the role, the value, and the range on its own. A custom meter is a generic element, an <svg>, or an <img> given role="meter" and ARIA value properties, which code keeps in step with the measurement.
A meter differs from a progress bar, which shows how far a task has gone and only moves toward completion. A meter's value can rise and fall. It also differs from a slider, which shows a value in a range that users set themselves.
When to Use
Use a meter when:
- You need to show a measurement that has a meaningful minimum and maximum, such as disk usage, battery charge, or a password strength score.
- Users benefit from a quick sense of where the value sits in its range, or whether it's low, high, or close to ideal.
- The value can go up or down over time.
Do not use a meter when:
- You're showing progress through a task, such as an upload or the steps of a wizard. Use a progress bar.
- The value has no meaningful maximum, such as a population count or a running total. A meter with an invented upper limit gives users a false sense of scale.
- Users choose the value. Use a slider.
Examples
Code in this section is meant to demonstrate techniques rather than requirements and lacks features needed in a production application.
Native HTML Meter
The <meter> element needs only HTML. Its value, min, and max attributes report a battery level of 15 out of 100, and the <label> element names it. The low, high, and optimum attributes tell the browser that 15 falls in the low range, which changes the meter's color. The text inside <meter> is fallback content for browsers that can't render the element, not its accessible name.
Native meter HTML
<label for="battery-level">
Battery level
</label>
<meter
id="battery-level"
min="0"
max="100"
low="20"
high="80"
optimum="90"
value="15">15%</meter>Custom ARIA Meter
The custom meter carries role="meter" and takes its accessible name from the visible label through aria-labelledby. Its range runs from 0 to 500 gigabytes, so it declares aria-valuemin and aria-valuemax. Its aria-valuetext gives the value with its unit and says the level is critical, which the fill's color shows only to people who can see it.
The track and fill inside the meter are decoration, and they're presentational, like every descendant of an element with role="meter".
ARIA meter HTML
<div id="disk-label">
Disk space used
</div>
<div
id="disk-meter"
class="meter"
role="meter"
aria-labelledby="disk-label"
aria-valuemin="0"
aria-valuemax="500"
aria-valuenow="450"
aria-valuetext="450 GB of 500 GB, critical">
<div
class="meter__fill meter__fill--critical"
style="width: 90%"></div>
</div>ARIA meter CSS
The fill draws a border rather than a background, so it stays visible in forced colors modes, such as Windows High Contrast.
.meter {
width: 100%;
border: 2px solid gray;
}
.meter__fill {
height: 0;
border-bottom: 8px solid green;
}
.meter__fill--critical {
border-bottom-color: darkred;
}JavaScript sets the value, the value text, and the fill from the same figure, so what users see and what assistive technology reports stay in step as the measurement changes.
ARIA meter JavaScript
function setDiskUsed(gigabytes) {
const max = 500
const value = Math.min(
max,
Math.max(0, Math.round(gigabytes))
)
const critical = value >= 450
const meter = document.getElementById('disk-meter')
meter.setAttribute('aria-valuenow', String(value))
meter.setAttribute(
'aria-valuetext',
`${value} GB of ${max} GB` +
(critical ? ', critical' : '')
)
const fill = meter.querySelector('.meter__fill')
fill.style.width = `${(value / max) * 100}%`
fill.classList.toggle(
'meter__fill--critical',
critical
)
}Structure and Semantics
Users need to know what a meter measures and where its value sits. A meter conveys that through three things: the meter role, an accessible name that identifies the measurement, and a value within a range.
The native <meter> element supplies the role and reports its value from its value, min, and max attributes. Its min defaults to 0 and its max to 1, not 100, and the browser keeps value within those limits. A <label> element can name a <meter> element, as it names a form field.
The low, high, and optimum attributes divide the range into regions the browser shows with color, but no ARIA property carries them, so assistive technology doesn't report which region the value is in. When that matters, say it in aria-valuetext or in visible text.
A custom meter declares role="meter" on the element that represents the whole meter, and reports its value with aria-valuenow, which the meter role requires. Its range defaults to 0 to 100, so aria-valuemin is required only when the minimum isn't 0, and aria-valuemax only when the maximum isn't 100. Setting them anyway is best practice, so the markup states the range rather than relying on the defaults.
The meter role takes its accessible name only from the author, never from its contents, and makes all of its descendants presentational. Text placed inside a custom meter doesn't name it, and a link or a button placed inside it loses its role. Keep the label and any related controls outside the meter.
| Attribute | How to use |
|---|---|
role="meter" | Custom meter. Set on the element representing the whole meter, not on its fill. Not needed on <meter>, which carries the role implicitly. |
aria-valuenow | Custom meter. Required. Set to the current value, within the range, and update it as the measurement changes. A native <meter> uses its value attribute instead. |
aria-valuemin / aria-valuemax | Custom meter. aria-valuemin is required when the minimum isn't 0, and aria-valuemax when the maximum isn't 100. Both are best practice when they match those defaults. A native <meter> uses its min and max attributes instead. |
low / high / optimum | Native <meter> only. Mark the low, high, and ideal regions of the range, which the browser shows with color. They have no ARIA equivalent. |
aria-valuetext | Either construction. Optional. Set to a readable form of the value when the number alone isn't meaningful, such as "50% (6 hours) remaining". |
aria-labelledby / aria-label | Either construction. Names the measurement. Point aria-labelledby at visible text, and use aria-label only when there's none. A native <meter> can use a <label> element instead. |
Role
A meter exposes the meter role on the element that carries its value and its accessible name. The <meter> element supplies the role on its own. A custom meter declares role="meter" on its outer element, the one holding aria-valuenow, not on the fill or the track inside it.
Has the correct role
Reported as: Element has incorrect role
A meter must expose the meter role.
When a custom meter is built from styled <div> elements with no role, assistive technology exposes it as plain content or ignores it, and screen reader users aren't told there's a measurement there at all. The value properties also have no role to attach to, so the value isn't reported either. A meter given role="progressbar" is reported as a task underway, which tells users to wait for something that will never finish.
Use the <meter> element, or set role="meter" on the element representing the whole meter.
Severity: Critical
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Applies role to the correct element
Reported as: Incorrect root element
Sanity check. Evinced checks that the meter role sits on the element that holds the meter's value and accessible name, not on an element around it or inside it. This check runs on every UI pattern, not only on meters.
A meter should carry the meter role on its outer element, together with its value properties and its accessible name.
When the role sits on the inner fill while the value properties and the name sit on the wrapper, or the other way around, no single element holds the role, the value, and the name. Screen reader users may get a meter with no value or no name, next to an element with a value and no role.
Put role="meter", the value properties, and the accessible name on one element, and keep the fill and track free of roles.
Accessibility Label
A meter needs an accessible name that identifies what it measures, such as "Battery level" or "CPU usage". The name never comes from the meter's contents, so you have to supply it. Use a <label> element for a native <meter>, or aria-labelledby pointing at visible text for either construction. Fall back to aria-label when there's no visible text.
Names a container that needs one
Reported as: Missing contextual labeling
A meter must have an accessible name that says what it measures.
When a meter has no name, screen reader users hear something like "meter, 90 percent" with no way to tell what is at 90 percent. On a dashboard with several meters, they can't tell storage from memory, or which reading is the one to worry about. A visible label beside the meter doesn't help unless it's connected.
Connect the visible label to the meter, with a <label> element for a native <meter> or aria-labelledby for either construction. When there's no visible label, set aria-label.
Severity: Moderate
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 1.3.1 Info and Relationships (A) | Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. |
| EN 301 549 | 9.1.3.1 Info and Relationships | Same as the WCAG text. |
aria-valuetext
When a percentage alone doesn't tell users what a meter reads, aria-valuetext gives a readable form of the value, such as "Current temperature is 75 degrees Fahrenheit" or "450 GB of 500 GB, critical". Assistive technology reports the text in place of the number, so update the text every time the value changes, and keep aria-valuenow set alongside it on a custom meter.
A native <meter> element can carry aria-valuetext too, and the value text is the way to report the low or high region its color shows.
Uses value text to add meaning
Reported as: Meaningful aria-valuetext
A meter's aria-valuetext should say something its number doesn't.
When aria-valuetext repeats the value, such as "50" for a value of 50, screen reader users hear less than the default percentage would have told them. The text also replaces the number in what assistive technology reports, so if it isn't updated with the value, screen reader users hear a reading the meter no longer shows.
Leave aria-valuetext off when the percentage speaks for itself. When it doesn't, set text that adds the missing context, such as the unit, the time remaining, or whether the level is low, and update it in the same place as the value.
Severity: Minor
Values
A meter reports its measurement as a value within a range, and assistive technology usually presents that value as a percentage of the range. Unlike a progress bar, a meter is never indeterminate: it always has a current value to report, so a custom meter always sets aria-valuenow.
Leaves native values to HTML
Reported as: Avoid ARIA values on native inputs
A native <meter> element must not also carry aria-valuenow, aria-valuemin, or aria-valuemax.
When a <meter> element has ARIA value properties alongside its value, min, and max attributes, the two can disagree. Script updates value as the measurement changes while the ARIA properties keep their first values, so screen reader users can hear a reading the meter no longer shows.
Remove the ARIA value properties and let value, min, and max report the measurement. aria-valuetext has no native counterpart, so keep it when the number needs explaining.
Severity: Critical
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Orders its limits low to high
Reported as: Min value is greater than the max value
A meter's minimum must be lower than its maximum.
When aria-valuemin is greater than aria-valuemax, the range contains no value. Assistive technology can't place the value within it, so screen reader users hear a negative percentage or a bare number with no sense of whether the reading is high or low.
Sort the two limits before declaring them, including limits taken from data, so the smaller one is always the minimum. Declare a descending scale low to high too, and handle its direction in the presentation.
Severity: Critical
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Reports its value and its limits
Reported as: Missing range attributes
A meter must report its current value, together with its range, to assistive technology.
When a custom meter moves its fill but never sets aria-valuenow, screen reader users are told there's a meter but not what it reads. When limits are missing, a custom meter runs to 100, so screen reader users hear a rating of 4 out of 5 as "4 percent". A native <meter> runs to 1, so a value of 40 is held at the top of the range.
Set aria-valuenow and update it in the same code that moves the fill. Declare aria-valuemin whenever the minimum isn't 0 and aria-valuemax whenever the maximum isn't 100, and set them anyway when they match those defaults, so the markup states the range rather than relying on the defaults. On a <meter> element, set min whenever the minimum isn't 0 and max whenever the maximum isn't 1.
Severity: Critical
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Spans more than a single value
Reported as: Range has equal min and max values
A meter's range must have room for more than one value, with a maximum above its minimum.
When the minimum and maximum are equal, such as limits taken from data that holds only one reading so far, every value is both the bottom and the top of the range. Assistive technology can't express the value as a share of a range with no width, and screen reader users hear a figure that tells them nothing about whether it's high or low.
Check that the limits differ before declaring them. When the data can't supply a real range yet, show the reading as text instead of as a meter.
Severity: Critical
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
aria-invalid
A meter has no invalid state to report. Users never enter its value, and ARIA 1.2 deprecated aria-invalid on the meter role. A value that falls outside the range is a fault in the code that sets it, so fix the value rather than flagging it. A critical reading, such as a nearly full disk, isn't invalid either. Report it in the value text.
Does not declare aria-invalid
Reported as: False aria-invalid value
A meter must not carry aria-invalid.
A meter isn't an input, so users can't correct its value. When a meter carries aria-invalid="true", screen reader users are told about an error they can do nothing about. On a normal reading, they may distrust the measurement. A value outside the range isn't a state to report either: it's a fault in the code that sets it, which the code has to fix.
Remove aria-invalid from the meter, and keep its value within its range. Convey a critical reading, such as a nearly full disk, in its aria-valuetext or in visible text. When the measurement fails, such as a sensor that stops reporting, say so in text near the meter and set aria-describedby on the meter to that text's id. Drive warning styling from a class.
Severity: Serious
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Keeps the value within its bounds
Reported as: Value out of range
A meter's reported value must sit at or between its minimum and maximum.
When the value comes from data with a different range, or the maximum changes without the value following, the meter reports a figure its range can't contain. Screen reader users may hear "120 percent" on a range that stops at 100, or a percentage that bears no relation to the measurement.
Clamp the value to the limits whenever the value or the limits change, and set all three from the same source.
Severity: Serious
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Disabled
A meter is read-only, so it has nothing to disable. The <meter> element has no disabled attribute, and ARIA 1.2 deprecated aria-disabled on the meter role. When a meter has nothing current to report, such as a sensor that's offline, say so in the value text or in text near the meter rather than through a disabled state.
Never declares a disabled state
Reported as: Component does not support disabled state
A meter must not carry a disabled state.
When disabled or aria-disabled is set on a meter, assistive technology may drop the state silently or report the meter as unavailable, which tells users nothing about the measurement. A meter reported as unavailable doesn't say whether its reading is stale, missing, or still accurate.
Remove disabled and aria-disabled from the meter. Report a stale or missing reading in its aria-valuetext or in visible text beside it, and style the inactive look with CSS.
Severity: Serious
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Disables only elements that support it
Reported as: Element type does not support disabled state
An element in a meter must carry disabled or aria-disabled only when its role supports a disabled state.
When the state sits on an element whose role has none, such as a wrapper, a list item or a heading, assistive technology may drop it or report it on something users can't operate, while the control that really is unavailable is still reported as available.
Remove the attribute, as the section intro describes. When a related control is unavailable, disable that control instead.
Severity: Serious
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Avoids conflicting disabled states
Reported as: Conflicting disabled values
A meter must not carry disabled values that conflict.
When a meter carries both disabled and aria-disabled with values that disagree, such as disabled with aria-disabled="false", assistive technology can report a state different from the one the browser applies, on an element that has no disabled state to report.
Remove both attributes from the meter, as the section intro describes, and report a stale or missing reading in its aria-valuetext or in text beside it.
Severity: Serious
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Keeps disabled off the meter
Reported as: Element does not support the disabled attribute
A meter must not carry the HTML disabled attribute.
When disabled is set on a <meter> or on an element with the meter role, browsers ignore it. Nothing changes for users, and screen reader users hear nothing about a reading the design may show as inactive.
Remove the attribute, as the section intro describes. Report a stale or missing reading in the meter's aria-valuetext or in text beside it, and style the inactive look with CSS.
Severity: Serious
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Forbidden Interactive Children
A meter contains no interactive elements. The meter role makes everything inside it presentational, so a control placed inside loses its role and accessible name. A control related to the measurement, such as a link to free up storage, belongs beside the meter.
Avoids nested interactives
Reported as: Forbidden interactive children; Nested interactive elements
A meter must not contain an interactive element.
When a link or a button sits inside a meter, or is owned by one through aria-owns, it becomes presentational and drops out of the accessibility tree even though it's visible on screen. Screen reader users can't find or operate it, and keyboard users may tab to a control that assistive technology doesn't describe.
Move the control out of the meter, and out of any aria-owns list on it, and place it beside the meter with its own role, accessible name, and tab stop.
Severity: Serious
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 9.4.1.2 Name, Role, Value | Same as the WCAG text. |
| Section 508 | 1194.21(d) | Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. |
Relationships
A meter's main relationship is to its label. A <label> element names a native <meter>, and aria-labelledby names either construction from visible text elsewhere. When a meter needs more explanation than its name carries, such as what the low and high regions mean, set aria-describedby on the meter to the id of that text.
aria-owns
A meter is a single element whose children are presentational, so a label, an explanation, or a related link sits outside it and relates to it by reference. Nothing about a meter calls for aria-owns.
Avoids aria-owns
Reported as: Avoid aria-owns
General check. Evinced checks that the meter doesn't use aria-owns to claim elements elsewhere in the document as its children. This check runs on every UI pattern, not only on meters.
A meter should not own other elements with aria-owns.
When a meter owns its label, a description, or a link, those elements become its children, so they're presentational too. Depending on the browser and assistive technology, screen reader users may find the owned content missing from browse mode, folded into the meter's name, or read twice. When the owned content is focusable, focus can land on something with no role or name.
Remove aria-owns from the meter and keep the content outside it. Reference the label with aria-labelledby and any supporting text with aria-describedby.
Operation
A meter has no keyboard or pointer operation of its own: users read its value, and it takes no focus. When script on the page handles keys around it, the test below applies.
Event Listener Type
When script in a meter responds to keys, it listens for keydown or keyup. The keypress event is deprecated, and browsers don't fire it for many keys, including the arrow keys, Home, End and Escape.
Avoids the keypress event
Reported as: Deprecated keypress listener
A meter's key handling should use keydown or keyup, not keypress.
When a handler listens for keypress, keys the browser doesn't send through that event go unanswered, and keyboard users find the meter ignoring keys it's meant to respond to.
Replace each keypress listener with a keydown listener, and read the key from event.key.
Severity: Minor
FAQ
Which WCAG success criteria do the meter issues relate to?
Most relate to 4.1.2 Name, Role, Value: the meter role, reporting the value and its limits, ordering the limits and giving the range room for more than one value, leaving native values to HTML, keeping the value within its bounds, the invalid and disabled states, and keeping interactive elements out of the meter. The accessible name relates to 1.3.1 Info and Relationships.
Meaningful value text maps to no WCAG success criterion and is a best practice.
Why are some meter issues marked as Critical and others as Minor?
Severity reflects how much an issue gets in users' way. Critical issues stop users outright:
- A meter with no role
- A value or its limits not reported
- Limits in the wrong order or equal
- ARIA values that contradict a native meter
Serious issues confuse users though they can still read the measurement:
- An invalid or disabled state
- A value outside the range
- An interactive element inside the meter
Moderate issues leave users unsure what a reading is for, such as an unnamed meter.
Minor issues are smaller obstacles, such as value text that adds nothing to the number.
The aria-owns check and the check on where the role sits carry no severity: Evinced reports them as general and sanity checks.
Related Patterns
- Progress Bar: progress through a task, which only moves toward completion
- Slider: a value in a range that users set themselves