ARIA accessibility and AngularJS

[m.wil...@midlandhr.co.uk]

Hi,

I was hoping someone might be able to give me some advice or point me in the right direction. I am currently working on a project that has been asked to use AngularJS and after exploring many of the things that AngularJS can do I seem to have hit a problem when it comes to accessibility.

Simply, because of the approach taken in AngularJS (heavy DOM manipulation) and other MV* frameworks for that matter, it seems that there are several problems screen readers users face because of how they work with/rely on the DOM. After testing with screen readers and using ARIA to try and address these issues, it seems this is a drawback of using AngularJS. Not specifically because of AngularJS but because of the combination of AngularJS and the screen reader API.

So it short what I'm wondering is, has anyone else had to address accessibility when it comes to building a product based on AngularJS? Or can anyone point me to a few examples of sites built using AngularJS that claim to be accessible?

Thanks for any help!

[Peter]

I've played around with AngularJS a little what is the problem your running into? Would you have a code example? cheers, +pt

--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to free-aria+...@googlegroups.com.
To post to this group, send email to free...@googlegroups.com.
Visit this group at http://groups.google.com/group/free-aria?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[m.wil...@midlandhr.co.uk]

Hey Peter thanks for replying,

We are having a problem with how best to implement accessibility in areas of our (large) one page app that update angular views dynamically with content without a traditional page load. It doesn't seem to be Angular itself, rather any total javascript front end.

We thought that aria-live would be the answer but we are experiencing problems with it. We have tried to boil down the issues - see our simple test case table below, which we are adding to as we find what works or doesn't work and then will give to the vendors if appropriate.

http://custprevap.cloudapp.net/ttest_web/aria-tests/aria_live_screen_reader_support.html

Please look at the code and see whether we are missing something, or any best practice of doing it that you can advise.

Thankyou

m

[James Teh]

On 2/03/2013 1:18 AM, m.wil...@midlandhr.co.uk wrote:
> We are having a problem with how best to implement accessibility in
> areas of our (large) one page app that update angular views dynamically
> with content without a traditional page load. It doesn't seem to be
> Angular itself, rather any total javascript front end.

Can you be a bit more specific about what you expect from the screen
reader? What exactly is the problem you're having that you need to solve?

> We thought that aria-live would be the answer but we are experiencing
> problems with it.

What are you trying to do with aria-live? Imo, aria-live is best for
small pieces of content which are updated dynamically, not huge pieces
of content. You certainly don't want to use this to report an entire new
section of a page. Aside from anything else, it won't move the user's
cursor (or point of interest).

Jamie

--
James Teh
Director, NV Access Limited
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/
Phone: +61 7 5667 8372

[Benjamin Hawkes-Lewis]

On 2 March 2013 13:16, James Teh <ja...@nvaccess.org> wrote:
> What are you trying to do with aria-live? Imo, aria-live is best for small
> pieces of content which are updated dynamically, not huge pieces of content.
> You certainly don't want to use this to report an entire new section of a
> page. Aside from anything else, it won't move the user's cursor (or point of
> interest).

What do you think should be used to report the addition of a new
section or module to a page?

--
Benjamin Hawkes-Lewis

[James Teh]

On 2/03/2013 9:21 PM, Benjamin Hawkes-Lewis wrote:
>> Imo, aria-live is best for small
>> pieces of content which are updated dynamically, not huge pieces of content.
>> You certainly don't want to use this to report an entire new section of a
>> page.

> What do you think should be used to report the addition of a new
> section or module to a page?

I'd either move the focus or scroll to the new content using an anchor
(i.e. set an id on the target and change the browser location to jump
there).

[m.wil...@midlandhr.co.uk]

This is great guys, thank you - and Benjamin, that was my next question too!

Ok so I should be using focus() on the new content? What if the new content is not a form field, but a section of text that needs to be read first - How best would I handle that? Effectively there could be a wide variety of content dynamically updating in this main section. Or maybe when content loads use an anchor as you suggest to got the top of the content. Would that announce the new content on its own?

Sorry for the newbie questions.

m

[James Teh]

On 3/03/2013 1:23 AM, m.wil...@midlandhr.co.uk wrote:
> Ok so I should be using focus() on the new content? What if the new content is not a form field, but a section of text that needs to be read first - How best would I handle that? Effectively there could be a wide variety of content dynamically updating in this main section. Or maybe when content loads use an anchor as you suggest to got the top of the content. Would that announce the new content on its own?

As you say, using focus on something which isn't normally focusable is
probably a bit ugly. Using an anchor at the top would probably only
announce the first line in most screen readers (and move the cursor
there too), but that should be sufficient to suggest to a user that
there is specific content they should read.

[Peter]

Hi James, 

so your adding a new section/widget/thing to a page that is contained in a live region? How complex is the content and what screen reader are you using? If it helps to have some test cases, here are a few basic ones: http://test.cita.illinois.edu/aria/live/

You should be able to focus just about anything by adding a tabindex="-1" attribute and then using a focus() on the element - or maybe I misunderstood - more info http://www.w3.org/TR/wai-aria-practices/#kbd_focus

cheers,

+pt

m

[m.wil...@midlandhr.co.uk]

Hey Peter, James was just clarifying what he would do, in order to answer my question.

To summarise the question, we are prototyping a large single page app (everything loaded dynamically, built with AngularJS). In general there is a couple of navigation areas and a single main content area. We had thought that aria-live was the best way to get that new content read into that main area, but have very mixed results in practice on very simple test cases (http://custprevap.cloudapp.net/ttest_web/aria-tests/aria_live_screen_reader_support.html). 

The content we are going to have is varied - from forms, to straight text, to diagrams, to a combination of the 3.

We were advised here to use an anchor or focus() but both feel a bit like hacks, rather than what I thought aria-live promised to be. However if they are industry standard hacks, work consistently and are considered de-facto best practice, we can try and work them in to our standard new-content-loading routine.

- Mark

[James Teh]

On 4/03/2013 5:59 PM, m.wil...@midlandhr.co.uk wrote:
> We were advised here to use an anchor or focus() but both feel a bit
> like hacks

On the contrary, I'd argue they're more semantically correct. You
essentially want to draw the user's attention and point of interest to
the new content.

> rather than what I thought aria-live promised to be.

aria-live just reads new content as it changes. Even if it did work for
you, it wouldn't move the user's point of interest there. It'd also have
undesirable effects like reading any content changed by the user.

[Peter]

Yup what James said :) Though I remember having issues with heavily nested content in live-regions and DOM updates not always getting announced. Could you give us an example of the attributes you set on the container and inner content (jsfiddle.net)? Also, knowing which screenreader your testing with would be helpful (support can vary). cheers, +pt

--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to free-aria+unsubscribe@googlegroups.com.

[m.wil...@midlandhr.co.uk]

Thank you to both of you. James - that makes total sense and I'll put some tests together and report back.

I can't tell you how helpful that is - there seems very limited resources on the real-world intersection of thick client webapps and accessibility on the web. Luckily I found this group!

We are fortunate in terms of support as we sell the app, and can specify target browser reader combinations. So we are looking at IE(9+)/JAWS FF18/NVDA, Chrome/ChromeVox on Windows, and on Apple - Chrome/VO for OSX and Mobile Safari/VO for iOS 6.

Peter, in our tests using aria-live and aria-atomic with DOM manipulation, its just not ready for production across these combinations yet, but as we build our widget library I will get the team to post any issues to jsfiddle, and link to from here.

Thanks again for pointing us in the right direction and I'll be back here to report progress as soon as I can! m

[Peter]

Yup agreed, ARIA use cases, especially complex/real-world ones, are a little limited. So, if you'd be willing to perhaps take a few notes about what challenges you faced and what worked/didn't work while your working through your project, this could be quite useful/helpful!! Even if the result is just, the documentation is terrible, we had to figure this all out ourselves and here's how we did it :) cheers, +pt

--

You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.

To unsubscribe from this group and stop receiving emails from it, send an email to free-aria+...@googlegroups.com.