[Silk UI Web] SectionExpandable Accessibility Features

[Silk UI Web] SectionExpandable Accessibility Features

  
Forge Component
(52)
Published on 15 Nov (4 weeks ago) by OutSystems R&D
52 votes
Published on 15 Nov (4 weeks ago) by OutSystems R&D
As a university in the United States all of our sites have to be considered web accessible.  However, I am trying to use SectionExpandable because it looks and functions great and it is not accessible because there is no way for a user to get to and activate the section with a keyboard or using link list built into the screen reader.  In order to use this component we need this functionality.  Thoughts?
Hi Thomas,

Did you check this page to see where and how the SectionExpandable pattern can be used ?

https://labs.outsystems.net/silkui/PatternContent.aspx#PatternSectionExpandable

Thanks for Trying Ravi but that page is of no help to us.  It is implemented and works, etc. However, we just have no ability to expand each section using only a keyboard which is actually a requirement for it to be considered web accessible.  This is the general concern with most of silk ui.  We are wanting to use Silk UI, however, are required by law to make sure all of our webistes are web acccessible and it seems the case much of Silk UI is not.  I await any help.  
Hi Thomas

Silk UI provides various patterns that we could use in our application and make them accessible all over the world. In order to use the silk UI components, install the Silk UI application in your environment and drag and drop on your webscreen and pass required parameters. Please let me know if you want me provide a sample example of using sectionExpandable.
Hello Ravi.  I'm sorry we are talking about two different things in the terms of accessibility. I'm not talking about whether or not someone can access something from all across the world.  I'm talking about whether or not a person with disabilities, screen readers, limited motor skills ,etc. can successfully use and navigate the website.  Here is information on what I'm talking about https://www.w3.org/WAI/intro/accessibility.php  and these are the standards we need to follow https://www.w3.org/TR/WCAG20/

Our issue is that we have to abide by standards that say a user has to be able to use a website/web component using solely a keyboard or mouse (not both together but both seperate) and a user with section expandable cannot activate the section using only a keyboard.  Many of the components aren't accessible by the guidelines we have to follow.  Pretty much any institution of higher education in the United States (along with many in other countries) have to follow these guidelines/laws.  

Hopefull this helps explain the issues we are having.

Thank You.


Hi Thomas,

I would be interested in knowing what your conclusions were, it seems I have a similar problem now and will have to re-code large sections of my silk-ui website using different controls and probably no weblocks. 

Do you have any guidelines/advice/tips/techniques?

I think the OutSystems Accessibility paper should maybe have a section on what controls/silk ui features not to use and/or how to make them accessible for users using a keyboard.

Thanks

Keith


Does anyone know how to make the SilkUi Accordian accessible (as in WCAG 2.0 - has to be tabbable too and opened by a keyboard action) or does anyone have an implementation of an accessible accordion in OutSystems?


Thanks

Keith


Solution

Hi Keith!


As a quick workaround, you can make a copy of the AccordionItem for your application, and then, in the .AccordionVertical__header container add a tabindex property. Like this: http://prntscr.com/e0l3ru


Then you should add some styles for visual understanding of the focused element, like this:

.AccordionVertical__header:focus {
    background: #333;
    color: #fff;
}


And, in the end of your page place this little script:

$(document).ready(function() {
    $('.AccordionVertical__header').keydown(function(e){     
        if(e.which === 13){
           $(this).click();
        }
    });
});


With this, you should be able to navigate and trigger the click with your keyboard.


I'm attaching a sample .oml (P9.1). You can Publish and test it in your environment.

Solution

Hi Alexandre,

Thanks for that it works great!

Keith


Alexandre Santos wrote:

Hi Keith!


As a quick workaround, you can make a copy of the AccordionItem for your application, and then, in the .AccordionVertical__header container add a tabindex property. Like this: http://prntscr.com/e0l3ru


Then you should add some styles for visual understanding of the focused element, like this:

.AccordionVertical__header:focus {
    background: #333;
    color: #fff;
}


And, in the end of your page place this little script:

$(document).ready(function() {
    $('.AccordionVertical__header').keydown(function(e){     
        if(e.which === 13){
           $(this).click();
        }
    });
});


With this, you should be able to navigate and trigger the click with your keyboard.


I'm attaching a sample .oml (P9.1). You can Publish and test it in your environment.



Keith Matthews wrote:

Hi Alexandre

I always use Chrome and in Chrome this works great, but unfortunately in IE (11) it has the effect of also 'clicking' the first button on the screen, regardless of whether its default or not. Hard to believe!

Is there a simple workaround for IE?

Much appreciated.

Keith

Hi Alexandre,

Thanks for that it works great!

Keith


Alexandre Santos wrote:

Hi Keith!


As a quick workaround, you can make a copy of the AccordionItem for your application, and then, in the .AccordionVertical__header container add a tabindex property. Like this: http://prntscr.com/e0l3ru


Then you should add some styles for visual understanding of the focused element, like this:

.AccordionVertical__header:focus {
    background: #333;
    color: #fff;
}


And, in the end of your page place this little script:

$(document).ready(function() {
    $('.AccordionVertical__header').keydown(function(e){     
        if(e.which === 13){
           $(this).click();
        }
    });
});


With this, you should be able to navigate and trigger the click with your keyboard.


I'm attaching a sample .oml (P9.1). You can Publish and test it in your environment.





It does not fire links in IE , only buttons so that is one work around

OK changed it to respond to the spacebar instead of Enter and it stopped firing the button. Thanks

If you're looking to make your site compliant you'll want to make sure it works with Firefox.  Generally Firefox is what is used if people are using a screen reader because it works better for accessibility standards.  Google Chrome is yet to fix a good number of accessibility related issues many people run into with it that have been around for over a year.  

According to the client they only support IE and Chrome but we'll check it out in Firefox as well.

Thanks





Slight amendment. As I was generating a list of accordions with one item in each list, the tabindex was not controllable. Solution was to put a hidden link in the accordion title which made it tabbable in the correct sequence with other screen elements. Using same javascript to open it.

Thanks

Sorry Keith, didn't see your question in time. 


I've seen you already found an answer, but to clarify one thing. Have you put the hidden link inside the accordion title to trigger the click on the accordion header? Or is it something else?


Thanks

Yes I put the link in the accordion title to make it tabbable / focusable, and then use your javascript to open/close it.

I am essentially reading a list of questions and selectable answers from a database. The question goes in the accordion title and the select able (by checkbox) answers  go in the content. With the tabindex solution they all had the same tabindex so the tabbing / focus was unpredictable, using a link on the accordion title (question) all of the tabindex'es were generated in the correct sequence, and you can tab into the accordion title.

As the checkboxes needed to get a label I now have a pretty deep set of nested weblocks. But it works from an accessibility perspective, and from a functional persepctive.

All I have to do now is stop it tabbing to the answers insied the accordion when the accordion is closed. 

Thanks for your help.

Keith

Alexandre Santos wrote:

Sorry Keith, didn't see your question in time. 


I've seen you already found an answer, but to clarify one thing. Have you put the hidden link inside the accordion title to trigger the click on the accordion header? Or is it something else?


Thanks



Have you tested all these changes with a screen reader?  How does it read?

Thomas Burdick wrote:

Have you tested all these changes with a screen reader?  How does it read?

Not yet. I'll let you know but the HTML looks correct.


The screen reader (at least JAWS) reads all the text correctly for the hidden link and for the checkbox labels.

(This is a multilingual app also so what I am doing is displaying the question text (in current locale) and creating the same thing on the hidden link title. The link shows a fa "universal access" fa and the text has a font size of 0px so the actual wording of the link does not show. Focus goes to the link so looks like the icon is the focus. Works well no issues with the reader reading the various text)

However with JAWS active in IE & Chrome the javascript will not run to open the accordion, in Firefox there are no issues.

I read that JAWS takes a copy of the page and runs using that and sometimes it does not pick up the Javascript fast enough so does not operate on it. I guess Firefox solves that problem somehow.

So now I need to solve that problem for IE and Chrome somehow. Or we advise our users to use Firefox :-)

Anyone have a solution to the JAWS javascript issue?

Keith


Thomas Burdick wrote:

Have you tested all these changes with a screen reader?  How does it read?



Hi Thomas,

Did you figure out how to get aria-expanded true/false tags on your accordion?

Keith

No worries I figured it out.


Keith Matthews wrote:

Hi Thomas,

Did you figure out how to get aria-expanded true/false tags on your accordion?

Keith



No. didn't work as the refresh destroyed the data in the accordion.

Anyone know how to do this?


Keith Matthews wrote:

No worries I figured it out.


Keith Matthews wrote:

Hi Thomas,

Did you figure out how to get aria-expanded true/false tags on your accordion?

Keith





Hi Keith,


Can you explain better what is your problem right now? (print screens help if you can)


Keith Matthews wrote:

Hi Thomas,

Did you figure out how to get aria-expanded true/false tags on your accordion?

Keith

Regarding the Accordion, I think you just need to add or remove the "open" class to the "accordion item".

Hi Alexandre/Thomas

My problem was in order for the accordion to be fully accessible I had to get ARIA (accessibility) tags on the Accordion__header to state whether it was open or closed.

We resolved it with the following JavaScript on the AccordioItem weblock

SyntaxEditor Code Snippet

function SetOpenAriaExpanded(fieldId)
{
    element = document.getElementById(fieldId);
    var x = element.getAttribute("aria-expanded");
    if (x == "true") {
    element.setAttribute("aria-expanded", "false");
    }   else { 
    element.setAttribute("aria-expanded", "true");
    }
    return true;
}

So now it works fine.

Thanks for your help.

Keith

Has anyone found a way to make this accessible without making a copy of the accordion or expandable section?? I haven't been able to figure it out.