E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: Detlev Fischer
Date: Thu, Jun 04 2020 10:37AM
Subject: Best mark-up for process navigation
No previous message | Next message →

I'm trying to identify best practices accessibility-wise for process
navigation (sequence of steps).
I assume you want a list (ul) inside a nav element with some meaningful
name, like "process navigation".
Inside the ul you then have a number of steps (li elements); as you make
progress in the process, the past steps may become links if it is
possible to return to prior steps to change entries.
Then you have your current step which you want to mark up as
aria-current="step" (and presumably this step should be  link and not
static text, but I can't find confirmation for this in the ARIA spec or
authoring practices)
Then you have the future steps which may be marked up as li with strong
inside (instead of a with href).
Would it make sense to mark up future steps as a elements without href
so they cannot be tabbed to? (You would make sure via CSS they are not
shown as active or underlined)
Do you know of convincing implementations of process navigation that
cover the treatment of future steps?

Best, Detlev

From: Birkir R. Gunnarsson
Date: Thu, Jun 04 2020 12:52PM
Subject: Re: Best mark-up for process navigation
← Previous message | No next message

There is no official ARIA Authoring practices for this, but your
implementation sounds pretty close.
1. Put the process steps + content in a landmark region, rle="region"
or rle="complementary" and give it an accessible name such as
"progress" or "application process".
2. Code the process steps as an <ol>, indicate current step using
aria-current="step" on the <li>.
Start current step content with a heading underneath the <ol>, the
text of hte heading should correspond to the text of the step.
Then have next/previous buttons to navigate to adjacent steps.
Once user clicks those buttons you have to decide where focus goes, to
the list, to the heading or to the top of the widget, or stays on the
button and you use a live region to announce that content was updated.
Optional: Indicate finished steps, if you do it visually you can add a
label such as (completed) to the step name.
Whether you want users to be able to navigate directly to a step, then
you have to code them as a link.

Another implementation that I've used and I kind of like is to use a
tab component with next/previous buttons, Angular Material calls it
"Stepper"
https://material.angular.io/components/stepper
It's actually fairly accessible (Angular has its problems but it does
some things well).


<ol>
<li>

On 6/4/20, Detlev Fischer < = EMAIL ADDRESS REMOVED = > wrote:
> I'm trying to identify best practices accessibility-wise for process
> navigation (sequence of steps).
> I assume you want a list (ul) inside a nav element with some meaningful
> name, like "process navigation".
> Inside the ul you then have a number of steps (li elements); as you make
> progress in the process, the past steps may become links if it is
> possible to return to prior steps to change entries.
> Then you have your current step which you want to mark up as
> aria-current="step" (and presumably this step should be  link and not
> static text, but I can't find confirmation for this in the ARIA spec or
> authoring practices)
> Then you have the future steps which may be marked up as li with strong
> inside (instead of a with href).
> Would it make sense to mark up future steps as a elements without href
> so they cannot be tabbed to? (You would make sure via CSS they are not
> shown as active or underlined)
> Do you know of convincing implementations of process navigation that
> cover the treatment of future steps?
>
> Best, Detlev
> > > > >


--
Work hard. Have fun. Make history.