E-mail List Archives
Thread: JAWS 15 Vs JAWS 16 (Carousel widget example)
Number of posts in this thread: 8 (In chronological order)
From: Robert Fentress
Date: Tue, Feb 09 2016 12:22PM
Subject: JAWS 15 Vs JAWS 16 (Carousel widget example)
No previous message | Next message →
This is very dated, but in searching the list for suggestions on how
to implement a carousel pattern I came across this message. Though
the page Jon referenced is gone, I thought I'd offer up my experience,
for what it's worth.
I don't think listbox is semantically appropriate, as that is, as best
I can tell from the ARIA Authoring Practices document, intended to be
like a combobox that supports pictures. Structured content would not
map to the accessibility API. Basically, anything that would go in an
option would just be an accessible name, all read out as one blob.
Thus, things like headings and links, which you'll often see in
carousels, would not respond to virtual cursor-type navigation. If
all each carousel slide contains is an image, maybe this would be
okay, but, even then, it seems more wrong than right.
I don't particularly care for the WAI implementation Jennifer
mentioned, either. If I've navigated past the carousel, I certainly
don't want whatever I'm doing to be interrupted by an aria live region
announcing the contents of a slide, however politely. I suppose you
could make the argument that it is providing "equivalent"
functionality, in that a sighted user is also jolted out of whatever
it is they were focusing on, but I would hope the goal is to make
things more usable, not less.
The best I've been able to do is to use a sort of modified tab panel
structure. I add hidden text to the little bullets that let you
navigate between slides (making them bigger) and make these have the
tab role and wrap them in container set to the tablist role. The
container for the content of the slide is assigned the tabpanel role.
I set aria-controls and aria-selected appropriately and create
listeners for the up/down and left/right arrow events as ways of
moving between slides. Then, I add a play/pause button and recommend
that it start in the paused state (though, realistically, that advice
is not likely to be taken by folks).
One important thing I noticed is that you must handle focus
appropriately. For instance, if the user is on the tablist and the
carousel progresses to the next slide, you'll need to make sure to
move focus to the newly selected tab, or else it will be lost
entirely. Of course, you would only do this when you are interacting
with the tablist.
It would probably also be good to add a screen reader-only description
in there somewhere about how this is really a carousel, so that the
user isn't totally surprised about how this "tab panel" is behaving.
If you do feel it is important to notify user of changes, you could
compromise and use a polite live region to announce just the heading
of the slide.
I don't see a need to use the application role.
This is all horrible, I recognize, but its the best I, personally,
have been able to come up with. If best practice has evolved since
the original message was posted, I'd love to hear about it.
Best,
Rob
On Thu, Mar 12, 2015 at 4:12 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> Greetings, all:
>
> I wanted to post a pointer to this WAI carousel tutorial, in case folks
> don't know about it and might find it handy and/or might wish to provide
> comments for improvement, based on experience.
>
> See:
>
> http://www.w3.org/WAI/tutorials/carousels/
>
> Best,
> Jennifer
>
>
> > > --
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255
Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061
From: Jonathan Avila
Date: Tue, Feb 09 2016 3:03PM
Subject: Re: JAWS 15 Vs JAWS 16 (Carousel widget example)
← Previous message | Next message →
> This is very dated, but in searching the list for suggestions on how to implement a carousel pattern I came across this message. Though the page Jon referenced is gone, I thought I'd offer up my experience, for what it's worth.
I believe you are referring to my linking to a JQuery UI project that used a listbox role. I agree the structure of listbox items is essentially reduced -- so perhaps a one row grid might serve as a better although inadequate role.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Tuesday, February 09, 2016 2:23 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
This is very dated, but in searching the list for suggestions on how to implement a carousel pattern I came across this message. Though the page Jon referenced is gone, I thought I'd offer up my experience, for what it's worth.
I don't think listbox is semantically appropriate, as that is, as best I can tell from the ARIA Authoring Practices document, intended to be like a combobox that supports pictures. Structured content would not map to the accessibility API. Basically, anything that would go in an option would just be an accessible name, all read out as one blob.
Thus, things like headings and links, which you'll often see in carousels, would not respond to virtual cursor-type navigation. If all each carousel slide contains is an image, maybe this would be okay, but, even then, it seems more wrong than right.
I don't particularly care for the WAI implementation Jennifer mentioned, either. If I've navigated past the carousel, I certainly don't want whatever I'm doing to be interrupted by an aria live region announcing the contents of a slide, however politely. I suppose you could make the argument that it is providing "equivalent"
functionality, in that a sighted user is also jolted out of whatever it is they were focusing on, but I would hope the goal is to make things more usable, not less.
The best I've been able to do is to use a sort of modified tab panel structure. I add hidden text to the little bullets that let you navigate between slides (making them bigger) and make these have the tab role and wrap them in container set to the tablist role. The container for the content of the slide is assigned the tabpanel role.
I set aria-controls and aria-selected appropriately and create listeners for the up/down and left/right arrow events as ways of moving between slides. Then, I add a play/pause button and recommend that it start in the paused state (though, realistically, that advice is not likely to be taken by folks).
One important thing I noticed is that you must handle focus appropriately. For instance, if the user is on the tablist and the carousel progresses to the next slide, you'll need to make sure to move focus to the newly selected tab, or else it will be lost entirely. Of course, you would only do this when you are interacting with the tablist.
It would probably also be good to add a screen reader-only description in there somewhere about how this is really a carousel, so that the user isn't totally surprised about how this "tab panel" is behaving.
If you do feel it is important to notify user of changes, you could compromise and use a polite live region to announce just the heading of the slide.
I don't see a need to use the application role.
This is all horrible, I recognize, but its the best I, personally, have been able to come up with. If best practice has evolved since the original message was posted, I'd love to hear about it.
Best,
Rob
On Thu, Mar 12, 2015 at 4:12 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
> Greetings, all:
>
> I wanted to post a pointer to this WAI carousel tutorial, in case
> folks don't know about it and might find it handy and/or might wish to
> provide comments for improvement, based on experience.
>
> See:
>
> http://www.w3.org/WAI/tutorials/carousels/
>
> Best,
> Jennifer
>
>
> > > list messages to = EMAIL ADDRESS REMOVED =
--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255
Technology-enhanced Learning & Online Strategies Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061
From: Robert Fentress
Date: Tue, Feb 09 2016 5:12PM
Subject: Re: JAWS 15 Vs JAWS 16 (Carousel widget example)
← Previous message | Next message →
Thanks, Jon. Do you have an example I could take a look at? I'm having a
hard time imagining how that would work.
On Feb 9, 2016 5:03 PM, "Jonathan Avila" < = EMAIL ADDRESS REMOVED = > wrote:
> > This is very dated, but in searching the list for suggestions on how to
> implement a carousel pattern I came across this message. Though the page
> Jon referenced is gone, I thought I'd offer up my experience, for what it's
> worth.
>
> I believe you are referring to my linking to a JQuery UI project that used
> a listbox role. I agree the structure of listbox items is essentially
> reduced -- so perhaps a one row grid might serve as a better although
> inadequate role.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Robert Fentress
> Sent: Tuesday, February 09, 2016 2:23 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
>
> This is very dated, but in searching the list for suggestions on how to
> implement a carousel pattern I came across this message. Though the page
> Jon referenced is gone, I thought I'd offer up my experience, for what it's
> worth.
>
> I don't think listbox is semantically appropriate, as that is, as best I
> can tell from the ARIA Authoring Practices document, intended to be like a
> combobox that supports pictures. Structured content would not map to the
> accessibility API. Basically, anything that would go in an option would
> just be an accessible name, all read out as one blob.
> Thus, things like headings and links, which you'll often see in carousels,
> would not respond to virtual cursor-type navigation. If all each carousel
> slide contains is an image, maybe this would be okay, but, even then, it
> seems more wrong than right.
>
> I don't particularly care for the WAI implementation Jennifer mentioned,
> either. If I've navigated past the carousel, I certainly don't want
> whatever I'm doing to be interrupted by an aria live region announcing the
> contents of a slide, however politely. I suppose you could make the
> argument that it is providing "equivalent"
> functionality, in that a sighted user is also jolted out of whatever it is
> they were focusing on, but I would hope the goal is to make things more
> usable, not less.
>
> The best I've been able to do is to use a sort of modified tab panel
> structure. I add hidden text to the little bullets that let you navigate
> between slides (making them bigger) and make these have the tab role and
> wrap them in container set to the tablist role. The container for the
> content of the slide is assigned the tabpanel role.
> I set aria-controls and aria-selected appropriately and create listeners
> for the up/down and left/right arrow events as ways of moving between
> slides. Then, I add a play/pause button and recommend that it start in the
> paused state (though, realistically, that advice is not likely to be taken
> by folks).
>
> One important thing I noticed is that you must handle focus
> appropriately. For instance, if the user is on the tablist and the
> carousel progresses to the next slide, you'll need to make sure to move
> focus to the newly selected tab, or else it will be lost entirely. Of
> course, you would only do this when you are interacting with the tablist.
>
> It would probably also be good to add a screen reader-only description in
> there somewhere about how this is really a carousel, so that the user isn't
> totally surprised about how this "tab panel" is behaving.
> If you do feel it is important to notify user of changes, you could
> compromise and use a polite live region to announce just the heading of the
> slide.
>
> I don't see a need to use the application role.
>
> This is all horrible, I recognize, but its the best I, personally, have
> been able to come up with. If best practice has evolved since the original
> message was posted, I'd love to hear about it.
>
> Best,
> Rob
>
> On Thu, Mar 12, 2015 at 4:12 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = >
> wrote:
> > Greetings, all:
> >
> > I wanted to post a pointer to this WAI carousel tutorial, in case
> > folks don't know about it and might find it handy and/or might wish to
> > provide comments for improvement, based on experience.
> >
> > See:
> >
> > http://www.w3.org/WAI/tutorials/carousels/
> >
> > Best,
> > Jennifer
> >
> >
> > > > > > list messages to = EMAIL ADDRESS REMOVED =
>
>
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies Assistive Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > at http://webaim.org/discussion/archives
> > > > > >
From: Bryan Garaventa
Date: Tue, Feb 09 2016 5:51PM
Subject: Re: JAWS 15 Vs JAWS 16 (Carousel widget example)
← Previous message | Next message →
Unfortunately carousels can be a pain, since there are so many variables that go into it. E.G mouse interaction pausing and resuming interaction, the same when focus moves into or out of it, the pausing or resuming when desired via an explicit action, and the announcement of slides when manually switching panes though not doing so automatically all the time.
Often this is made more complicated than it needs to be. For example you can make an accessible carousel using standard links and buttons and don't actually need ARIA Tab markup, nor role=grid plus left right navigation, nor ARIA Listbox markup, all of which is usually overkill in many cases.
This implementation is based on the WAI Carousel Tutorial
http://whatsock.com/tsg/Coding%20Arena/Carousels,%20Slideshows,%20and%20Wizards/Carousel%20(Flat%20from%20XML%20with%20Overrides)/demo.htm
Which can also be downloaded from
http://whatsock.com/test/Carousel%20(Flat%20from%20XML%20with%20Overrides).zip
If you want to change the content in the slides. This is pulled from the CDATA tag within the XML file, and accepts any kind of markup including active elements.
Earlier aria-live was mentioned, but this wasn't meant to be used every time a slide changes, just when a slide is manually invoked using the Next or Previous buttons for instance, so that the user is notified of the content change without requiring focus to be moved somewhere else.
Otherwise, when focus is elsewhere on the page, the changing content is ignored by ATs by setting aria-live to âoff'.
Hopefully this helps a bit.
All the best,
Bryan
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Tuesday, February 09, 2016 4:13 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
Thanks, Jon. Do you have an example I could take a look at? I'm having a hard time imagining how that would work.
On Feb 9, 2016 5:03 PM, "Jonathan Avila" < <mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED = > wrote:
> > This is very dated, but in searching the list for suggestions on how
> > to
> implement a carousel pattern I came across this message. Though the
> page Jon referenced is gone, I thought I'd offer up my experience, for
> what it's worth.
>
> I believe you are referring to my linking to a JQuery UI project that
> used a listbox role. I agree the structure of listbox items is
> essentially reduced -- so perhaps a one row grid might serve as a
> better although inadequate role.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> <mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
> -----Original Message-----
> From: WebAIM-Forum [ <mailto: = EMAIL ADDRESS REMOVED = > mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Robert Fentress
> Sent: Tuesday, February 09, 2016 2:23 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
>
> This is very dated, but in searching the list for suggestions on how
> to implement a carousel pattern I came across this message. Though
> the page Jon referenced is gone, I thought I'd offer up my experience,
> for what it's worth.
>
> I don't think listbox is semantically appropriate, as that is, as best
> I can tell from the ARIA Authoring Practices document, intended to be
> like a combobox that supports pictures. Structured content would not
> map to the accessibility API. Basically, anything that would go in an
> option would just be an accessible name, all read out as one blob.
> Thus, things like headings and links, which you'll often see in
> carousels, would not respond to virtual cursor-type navigation. If
> all each carousel slide contains is an image, maybe this would be
> okay, but, even then, it seems more wrong than right.
>
> I don't particularly care for the WAI implementation Jennifer
> mentioned, either. If I've navigated past the carousel, I certainly
> don't want whatever I'm doing to be interrupted by an aria live region
> announcing the contents of a slide, however politely. I suppose you
> could make the argument that it is providing "equivalent"
> functionality, in that a sighted user is also jolted out of whatever
> it is they were focusing on, but I would hope the goal is to make
> things more usable, not less.
>
> The best I've been able to do is to use a sort of modified tab panel
> structure. I add hidden text to the little bullets that let you
> navigate between slides (making them bigger) and make these have the
> tab role and wrap them in container set to the tablist role. The
> container for the content of the slide is assigned the tabpanel role.
> I set aria-controls and aria-selected appropriately and create
> listeners for the up/down and left/right arrow events as ways of
> moving between slides. Then, I add a play/pause button and recommend
> that it start in the paused state (though, realistically, that advice
> is not likely to be taken by folks).
>
> One important thing I noticed is that you must handle focus
> appropriately. For instance, if the user is on the tablist and the
> carousel progresses to the next slide, you'll need to make sure to
> move focus to the newly selected tab, or else it will be lost
> entirely. Of course, you would only do this when you are interacting with the tablist.
>
> It would probably also be good to add a screen reader-only description
> in there somewhere about how this is really a carousel, so that the
> user isn't totally surprised about how this "tab panel" is behaving.
> If you do feel it is important to notify user of changes, you could
> compromise and use a polite live region to announce just the heading
> of the slide.
>
> I don't see a need to use the application role.
>
> This is all horrible, I recognize, but its the best I, personally,
> have been able to come up with. If best practice has evolved since
> the original message was posted, I'd love to hear about it.
>
> Best,
> Rob
>
> On Thu, Mar 12, 2015 at 4:12 PM, Jennifer Sutton < <mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED = >
> wrote:
> > Greetings, all:
> >
> > I wanted to post a pointer to this WAI carousel tutorial, in case
> > folks don't know about it and might find it handy and/or might wish
> > to provide comments for improvement, based on experience.
> >
> > See:
> >
> > <http://www.w3.org/WAI/tutorials/carousels/>; http://www.w3.org/WAI/tutorials/carousels/
> >
> > Best,
> > Jennifer
> >
> >
> > > > > > list messages to <mailto: = EMAIL ADDRESS REMOVED = > = EMAIL ADDRESS REMOVED =
>
>
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies Assistive
> Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > archives at <http://webaim.org/discussion/archives>; http://webaim.org/discussion/archives
> > > > archives at <http://webaim.org/discussion/archives>; http://webaim.org/discussion/archives
> >
From: Jonathan Avila
Date: Tue, Feb 09 2016 6:15PM
Subject: Re: JAWS 15 Vs JAWS 16 (Carousel widget example)
← Previous message | Next message →
> Thanks, Jon. Do you have an example I could take a look at? I'm having a hard time imagining how that would work.
I don't have an example -- and I'm not saying it's optimal but my goal of using something other than links would be to get all of the links from inside a carousel out of the swipe or tab order. I've seen some carousels that have hundreds of items and swiping or tabbing takes you through all of them. Of course being forced into forms/focus mode means you could not review content word by word as easily without going out of forms/focus mode. So Bryan's recommendation is sound -- I'm just theorizing how one could make a carousel that was one tab stop accessible.
Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
Sent: Tuesday, February 09, 2016 7:13 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
Thanks, Jon. Do you have an example I could take a look at? I'm having a hard time imagining how that would work.
On Feb 9, 2016 5:03 PM, "Jonathan Avila" < = EMAIL ADDRESS REMOVED = > wrote:
> > This is very dated, but in searching the list for suggestions on how
> > to
> implement a carousel pattern I came across this message. Though the
> page Jon referenced is gone, I thought I'd offer up my experience, for
> what it's worth.
>
> I believe you are referring to my linking to a JQuery UI project that
> used a listbox role. I agree the structure of listbox items is
> essentially reduced -- so perhaps a one row grid might serve as a
> better although inadequate role.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Robert Fentress
> Sent: Tuesday, February 09, 2016 2:23 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
>
> This is very dated, but in searching the list for suggestions on how
> to implement a carousel pattern I came across this message. Though
> the page Jon referenced is gone, I thought I'd offer up my experience,
> for what it's worth.
>
> I don't think listbox is semantically appropriate, as that is, as best
> I can tell from the ARIA Authoring Practices document, intended to be
> like a combobox that supports pictures. Structured content would not
> map to the accessibility API. Basically, anything that would go in an
> option would just be an accessible name, all read out as one blob.
> Thus, things like headings and links, which you'll often see in
> carousels, would not respond to virtual cursor-type navigation. If
> all each carousel slide contains is an image, maybe this would be
> okay, but, even then, it seems more wrong than right.
>
> I don't particularly care for the WAI implementation Jennifer
> mentioned, either. If I've navigated past the carousel, I certainly
> don't want whatever I'm doing to be interrupted by an aria live region
> announcing the contents of a slide, however politely. I suppose you
> could make the argument that it is providing "equivalent"
> functionality, in that a sighted user is also jolted out of whatever
> it is they were focusing on, but I would hope the goal is to make
> things more usable, not less.
>
> The best I've been able to do is to use a sort of modified tab panel
> structure. I add hidden text to the little bullets that let you
> navigate between slides (making them bigger) and make these have the
> tab role and wrap them in container set to the tablist role. The
> container for the content of the slide is assigned the tabpanel role.
> I set aria-controls and aria-selected appropriately and create
> listeners for the up/down and left/right arrow events as ways of
> moving between slides. Then, I add a play/pause button and recommend
> that it start in the paused state (though, realistically, that advice
> is not likely to be taken by folks).
>
> One important thing I noticed is that you must handle focus
> appropriately. For instance, if the user is on the tablist and the
> carousel progresses to the next slide, you'll need to make sure to
> move focus to the newly selected tab, or else it will be lost
> entirely. Of course, you would only do this when you are interacting with the tablist.
>
> It would probably also be good to add a screen reader-only description
> in there somewhere about how this is really a carousel, so that the
> user isn't totally surprised about how this "tab panel" is behaving.
> If you do feel it is important to notify user of changes, you could
> compromise and use a polite live region to announce just the heading
> of the slide.
>
> I don't see a need to use the application role.
>
> This is all horrible, I recognize, but its the best I, personally,
> have been able to come up with. If best practice has evolved since
> the original message was posted, I'd love to hear about it.
>
> Best,
> Rob
>
> On Thu, Mar 12, 2015 at 4:12 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = >
> wrote:
> > Greetings, all:
> >
> > I wanted to post a pointer to this WAI carousel tutorial, in case
> > folks don't know about it and might find it handy and/or might wish
> > to provide comments for improvement, based on experience.
> >
> > See:
> >
> > http://www.w3.org/WAI/tutorials/carousels/
> >
> > Best,
> > Jennifer
> >
> >
> > > > > > list messages to = EMAIL ADDRESS REMOVED =
>
>
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies Assistive
> Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
From: Detlev Fischer
Date: Tue, Feb 09 2016 10:36PM
Subject: Re: JAWS 15 Vs JAWS 16 (Carousel widget example)
← Previous message | Next message →
hoerkomm uses a carousel that is just structured as a group of h3 sections led by a hidden h2 explaining that to follow are animated teasers for selected offers of the site:
http://www.hoerkomm.de/start.html
So in this case, no aria markup and hidden sections not in the tab order. Otherwise I think tab panel would be the most fitting semantic structure.
On 9 Feb 2016, at 23:03, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> This is very dated, but in searching the list for suggestions on how to implement a carousel pattern I came across this message. Though the page Jon referenced is gone, I thought I'd offer up my experience, for what it's worth.
>
> I believe you are referring to my linking to a JQuery UI project that used a listbox role. I agree the structure of listbox items is essentially reduced -- so perhaps a one row grid might serve as a better although inadequate role.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Robert Fentress
> Sent: Tuesday, February 09, 2016 2:23 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
>
> This is very dated, but in searching the list for suggestions on how to implement a carousel pattern I came across this message. Though the page Jon referenced is gone, I thought I'd offer up my experience, for what it's worth.
>
> I don't think listbox is semantically appropriate, as that is, as best I can tell from the ARIA Authoring Practices document, intended to be like a combobox that supports pictures. Structured content would not map to the accessibility API. Basically, anything that would go in an option would just be an accessible name, all read out as one blob.
> Thus, things like headings and links, which you'll often see in carousels, would not respond to virtual cursor-type navigation. If all each carousel slide contains is an image, maybe this would be okay, but, even then, it seems more wrong than right.
>
> I don't particularly care for the WAI implementation Jennifer mentioned, either. If I've navigated past the carousel, I certainly don't want whatever I'm doing to be interrupted by an aria live region announcing the contents of a slide, however politely. I suppose you could make the argument that it is providing "equivalent"
> functionality, in that a sighted user is also jolted out of whatever it is they were focusing on, but I would hope the goal is to make things more usable, not less.
>
> The best I've been able to do is to use a sort of modified tab panel structure. I add hidden text to the little bullets that let you navigate between slides (making them bigger) and make these have the tab role and wrap them in container set to the tablist role. The container for the content of the slide is assigned the tabpanel role.
> I set aria-controls and aria-selected appropriately and create listeners for the up/down and left/right arrow events as ways of moving between slides. Then, I add a play/pause button and recommend that it start in the paused state (though, realistically, that advice is not likely to be taken by folks).
>
> One important thing I noticed is that you must handle focus appropriately. For instance, if the user is on the tablist and the carousel progresses to the next slide, you'll need to make sure to move focus to the newly selected tab, or else it will be lost entirely. Of course, you would only do this when you are interacting with the tablist.
>
> It would probably also be good to add a screen reader-only description in there somewhere about how this is really a carousel, so that the user isn't totally surprised about how this "tab panel" is behaving.
> If you do feel it is important to notify user of changes, you could compromise and use a polite live region to announce just the heading of the slide.
>
> I don't see a need to use the application role.
>
> This is all horrible, I recognize, but its the best I, personally, have been able to come up with. If best practice has evolved since the original message was posted, I'd love to hear about it.
>
> Best,
> Rob
>
> On Thu, Mar 12, 2015 at 4:12 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>> Greetings, all:
>>
>> I wanted to post a pointer to this WAI carousel tutorial, in case
>> folks don't know about it and might find it handy and/or might wish to
>> provide comments for improvement, based on experience.
>>
>> See:
>>
>> http://www.w3.org/WAI/tutorials/carousels/
>>
>> Best,
>> Jennifer
>>
>>
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>
>
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies Assistive Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > > > > > --
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
ThedestraÃe 2
22767 Hamburg
Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
From: Jonathan Avila
Date: Wed, Feb 10 2016 6:24AM
Subject: Re: JAWS 15 Vs JAWS 16 (Carousel widget example)
← Previous message | Next message →
> So in this case, no aria markup and hidden sections not in the tab order
In the carousel cases like you describe with a small number of panels that slide and in out on a home page I totally agree -- a non-ARIA approach like the one discussed in the WAI Carousel tutorial is what I'd recommend.
My comments were purely around carousels such as those found in video streaming sites or retail sites that likely contain hundreds if not thousands of items consisting mainly of a small picture and a view words that are links. In some cases these carousels may even contain 2 or more rows of items in the same carousel. The idea of multiple rows in a carousel is not that uncommon and starts looking more like a scrolling grid.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Detlev Fischer
Sent: Wednesday, February 10, 2016 12:36 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
hoerkomm uses a carousel that is just structured as a group of h3 sections led by a hidden h2 explaining that to follow are animated teasers for selected offers of the site:
http://www.hoerkomm.de/start.html
So in this case, no aria markup and hidden sections not in the tab order. Otherwise I think tab panel would be the most fitting semantic structure.
On 9 Feb 2016, at 23:03, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> This is very dated, but in searching the list for suggestions on how to implement a carousel pattern I came across this message. Though the page Jon referenced is gone, I thought I'd offer up my experience, for what it's worth.
>
> I believe you are referring to my linking to a JQuery UI project that used a listbox role. I agree the structure of listbox items is essentially reduced -- so perhaps a one row grid might serve as a better although inadequate role.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Robert Fentress
> Sent: Tuesday, February 09, 2016 2:23 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
>
> This is very dated, but in searching the list for suggestions on how to implement a carousel pattern I came across this message. Though the page Jon referenced is gone, I thought I'd offer up my experience, for what it's worth.
>
> I don't think listbox is semantically appropriate, as that is, as best I can tell from the ARIA Authoring Practices document, intended to be like a combobox that supports pictures. Structured content would not map to the accessibility API. Basically, anything that would go in an option would just be an accessible name, all read out as one blob.
> Thus, things like headings and links, which you'll often see in carousels, would not respond to virtual cursor-type navigation. If all each carousel slide contains is an image, maybe this would be okay, but, even then, it seems more wrong than right.
>
> I don't particularly care for the WAI implementation Jennifer mentioned, either. If I've navigated past the carousel, I certainly don't want whatever I'm doing to be interrupted by an aria live region announcing the contents of a slide, however politely. I suppose you could make the argument that it is providing "equivalent"
> functionality, in that a sighted user is also jolted out of whatever it is they were focusing on, but I would hope the goal is to make things more usable, not less.
>
> The best I've been able to do is to use a sort of modified tab panel structure. I add hidden text to the little bullets that let you navigate between slides (making them bigger) and make these have the tab role and wrap them in container set to the tablist role. The container for the content of the slide is assigned the tabpanel role.
> I set aria-controls and aria-selected appropriately and create listeners for the up/down and left/right arrow events as ways of moving between slides. Then, I add a play/pause button and recommend that it start in the paused state (though, realistically, that advice is not likely to be taken by folks).
>
> One important thing I noticed is that you must handle focus appropriately. For instance, if the user is on the tablist and the carousel progresses to the next slide, you'll need to make sure to move focus to the newly selected tab, or else it will be lost entirely. Of course, you would only do this when you are interacting with the tablist.
>
> It would probably also be good to add a screen reader-only description in there somewhere about how this is really a carousel, so that the user isn't totally surprised about how this "tab panel" is behaving.
> If you do feel it is important to notify user of changes, you could compromise and use a polite live region to announce just the heading of the slide.
>
> I don't see a need to use the application role.
>
> This is all horrible, I recognize, but its the best I, personally, have been able to come up with. If best practice has evolved since the original message was posted, I'd love to hear about it.
>
> Best,
> Rob
>
> On Thu, Mar 12, 2015 at 4:12 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>> Greetings, all:
>>
>> I wanted to post a pointer to this WAI carousel tutorial, in case
>> folks don't know about it and might find it handy and/or might wish
>> to provide comments for improvement, based on experience.
>>
>> See:
>>
>> http://www.w3.org/WAI/tutorials/carousels/
>>
>> Best,
>> Jennifer
>>
>>
>> >> >> list messages to = EMAIL ADDRESS REMOVED =
>
>
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies Assistive
> Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> --
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese c/o feld.wald.wiese ThedestraÃe 2
22767 Hamburg
Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
From: Robert Fentress
Date: Wed, Feb 10 2016 9:52AM
Subject: Re: JAWS 15 Vs JAWS 16 (Carousel widget example)
← Previous message | No next message
Another thing to keep in mind, that I just noticed, is that you would
also have to watch out for the edge case where focus is on an element
in a slide and then the slide disappears. In such instances, you'd
have to set focus somewhere sensible--like maybe the newly active
slide button/tab? Man, carousels stink!
On Wed, Feb 10, 2016 at 8:24 AM, Jonathan Avila
< = EMAIL ADDRESS REMOVED = > wrote:
>> So in this case, no aria markup and hidden sections not in the tab order
>
> In the carousel cases like you describe with a small number of panels that slide and in out on a home page I totally agree -- a non-ARIA approach like the one discussed in the WAI Carousel tutorial is what I'd recommend.
>
> My comments were purely around carousels such as those found in video streaming sites or retail sites that likely contain hundreds if not thousands of items consisting mainly of a small picture and a view words that are links. In some cases these carousels may even contain 2 or more rows of items in the same carousel. The idea of multiple rows in a carousel is not that uncommon and starts looking more like a scrolling grid.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Detlev Fischer
> Sent: Wednesday, February 10, 2016 12:36 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
>
> hoerkomm uses a carousel that is just structured as a group of h3 sections led by a hidden h2 explaining that to follow are animated teasers for selected offers of the site:
> http://www.hoerkomm.de/start.html
>
> So in this case, no aria markup and hidden sections not in the tab order. Otherwise I think tab panel would be the most fitting semantic structure.
>
>
> On 9 Feb 2016, at 23:03, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>
>>> This is very dated, but in searching the list for suggestions on how to implement a carousel pattern I came across this message. Though the page Jon referenced is gone, I thought I'd offer up my experience, for what it's worth.
>>
>> I believe you are referring to my linking to a JQuery UI project that used a listbox role. I agree the structure of listbox items is essentially reduced -- so perhaps a one row grid might serve as a better although inadequate role.
>>
>> Jonathan
>>
>> --
>> Jonathan Avila
>> Chief Accessibility Officer
>> SSB BART Group
>> = EMAIL ADDRESS REMOVED =
>>
>> 703-637-8957 (o)
>> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On
>> Behalf Of Robert Fentress
>> Sent: Tuesday, February 09, 2016 2:23 PM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] JAWS 15 Vs JAWS 16 (Carousel widget example)
>>
>> This is very dated, but in searching the list for suggestions on how to implement a carousel pattern I came across this message. Though the page Jon referenced is gone, I thought I'd offer up my experience, for what it's worth.
>>
>> I don't think listbox is semantically appropriate, as that is, as best I can tell from the ARIA Authoring Practices document, intended to be like a combobox that supports pictures. Structured content would not map to the accessibility API. Basically, anything that would go in an option would just be an accessible name, all read out as one blob.
>> Thus, things like headings and links, which you'll often see in carousels, would not respond to virtual cursor-type navigation. If all each carousel slide contains is an image, maybe this would be okay, but, even then, it seems more wrong than right.
>>
>> I don't particularly care for the WAI implementation Jennifer mentioned, either. If I've navigated past the carousel, I certainly don't want whatever I'm doing to be interrupted by an aria live region announcing the contents of a slide, however politely. I suppose you could make the argument that it is providing "equivalent"
>> functionality, in that a sighted user is also jolted out of whatever it is they were focusing on, but I would hope the goal is to make things more usable, not less.
>>
>> The best I've been able to do is to use a sort of modified tab panel structure. I add hidden text to the little bullets that let you navigate between slides (making them bigger) and make these have the tab role and wrap them in container set to the tablist role. The container for the content of the slide is assigned the tabpanel role.
>> I set aria-controls and aria-selected appropriately and create listeners for the up/down and left/right arrow events as ways of moving between slides. Then, I add a play/pause button and recommend that it start in the paused state (though, realistically, that advice is not likely to be taken by folks).
>>
>> One important thing I noticed is that you must handle focus appropriately. For instance, if the user is on the tablist and the carousel progresses to the next slide, you'll need to make sure to move focus to the newly selected tab, or else it will be lost entirely. Of course, you would only do this when you are interacting with the tablist.
>>
>> It would probably also be good to add a screen reader-only description in there somewhere about how this is really a carousel, so that the user isn't totally surprised about how this "tab panel" is behaving.
>> If you do feel it is important to notify user of changes, you could compromise and use a polite live region to announce just the heading of the slide.
>>
>> I don't see a need to use the application role.
>>
>> This is all horrible, I recognize, but its the best I, personally, have been able to come up with. If best practice has evolved since the original message was posted, I'd love to hear about it.
>>
>> Best,
>> Rob
>>
>> On Thu, Mar 12, 2015 at 4:12 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = > wrote:
>>> Greetings, all:
>>>
>>> I wanted to post a pointer to this WAI carousel tutorial, in case
>>> folks don't know about it and might find it handy and/or might wish
>>> to provide comments for improvement, based on experience.
>>>
>>> See:
>>>
>>> http://www.w3.org/WAI/tutorials/carousels/
>>>
>>> Best,
>>> Jennifer
>>>
>>>
>>> >>> >>> list messages to = EMAIL ADDRESS REMOVED =
>>
>>
>>
>> --
>> Robert Fentress
>> Senior Accessibility Solutions Designer
>> 540.231.1255
>>
>> Technology-enhanced Learning & Online Strategies Assistive
>> Technologies
>> 1180 Torgersen Hall
>> 620 Drillfield Drive (0434)
>> Blacksburg, Virginia 24061
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >
> --
> Detlev Fischer
> testkreis - das Accessibility-Team von feld.wald.wiese c/o feld.wald.wiese ThedestraÃe 2
> 22767 Hamburg
>
> Mobil +49 (0)157 57 57 57 45
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
>
>
>
>
> > > > > > > --
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255
Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061