![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amazonv- Type: Breakout
- Track: Development
As front-end developers, we are tasked with building the front end of a Web site or application‚ in other words, we are building the user’s end of an interface. This is why it is crucial that we ensure that the front-end foundations that we build are as inclusive of and accessible to as many users as possible. To do that, we must build with accessibility in mind from the get-go. This, in turn, means that the way we approach writing HTML, CSS, SVG and JavaScript *might* need to change as we take into consideration many factors that affect how (in)accessible our UIs are.
This talk is a practical one, chock-full of tips for creating more accessible front-end foundations. If writing HTML, CSS, SVG and JavaScript is part of your job, then this talk is for you.
In this session — a series of macro case studies from real client projects — Sara shares some frustrations, many lessons learned, and a lot of practical tips and tricks for building accessible front-end foundations that you can take and apply in your own projects right away.
MISSED START
practical.
>> Because this is a recipe application also the time I going to have their hands busy or dirty when they were using it so we wanted to create a way you could navigate the application without actually having to touch a computer and get dirty so what we did was implemented voice navigation and let me show you how this works. You can click the little button here and watch as I talk and the application will navigate between sections.
--- Go to cupcakes.
---
Vanilla cupcakes.
---
Recipe.
---
So you can see how that creates the ability for us to navigate the application without ever having to touch our computer.
We can also use other hardware like the lead motion device which allows it to use gestural input when navigating our computer so I can input the device and it instantly recognizes it. We are using CSS's regions to breakout the content into different slides and instead of having to test the device to navigate we are actually using the lead emotions and you can use gestures to actually swipe to the content and continue cooking.
Another thing we can do is add more features to our application like a timer that allows us to count down how many men's we have left when cooking our cupcakes or adjust the quantity for example if you wanted 20 instead of 12 cupcakes I know exactly how many tablespoons of unsalted butter I need.
---
A great feature and challenge other web is that it fits on every screen so we really need to make our content responsive.
>> The application was built with user in mind and that is what made it so feature-rich and so practical.
To date I still remember how incredibly inspired I was when I watched the video; I was fascinated by the possibilities of what I could do and create using web technologies. But the idea that I had the ability to use tools that we have at our disposal to design and build solutions that serve people and make their lives better.
---
CJ could have created this application using cool, modern CSS features without adding the voice enhance support for the experience would not have been as inclusive or as practical but by doing so he created a more inclusive experience, a more human experience and above all a more memorable experience, one from which I still draw inspiration a little less after 10 years after its creation and by the way navigating a webpage using voice commands is actually more common than we think. Sometimes it is even the necessity for some users. I will touch more on that later during the talk.
---
Unfortunately today thinking about people means context, disabilities and preferences to creating experiences that work for everyone often sounds like a burden and a creativity killer but this application is living proof that this does not have to be the case. Oftentimes constrain fuels creativity. I really like the way that Microsoft expresses it on the inclusive design reference, a great resource created by Microsoft to encourage and push inclusive design is a push to creating a experiences on the web. It says expanding interactions to become more inclusive and seeing diversity differently as a dynamic inspiration for creative.
---
In order to design inclusive experiences we need to determine how our user uses interfaces and how users navigate the web. The cupcake app was an example of a context where the user would have difficult touching the screen with user hands and people could be browsing the web in a different context that affects the ability to use interfaces and some people are born with permanent disabilities that fundamentally change the way they perceive the world and other people might be browsing the web with a temporary's ability caused by an accident.
---
As with everything the more you do it the more efficient you get a doing it and the less of an effort and takes. In this talk I want to share some tips that are small and fairly easy to implement but can have a big impact on accessibility and inclusivity of your products.
---
The good news is that you can cover a lot of ground and create far more resilient and inclusive accessibility experience by starting with a solid foundation and the foundation of every accessible website is semantic HTML.
---
Semantic HTML is the universal language that only devices accessing the Internet understand, including but not limited to browsers, reading absent screen readers.
---
Each HTML element describes the type of content that it presents and using semantic HTML and using the correct HTML elements for the correct purpose is much as possible. If you have a heading use a heading element; if you have a paragraph you say p tag. Using the correct elements your country can have structure and meaning,
And you can quickly scan it and they can get a clear idea of which content is the main content, , Which content is complementary heading, section blocks and white space are used to indicate importance. The user can get a clear skeleton of the page just by looking at it but a visually impaired user cannot. They will often rely on screen reading software to convey content structure and meaning and screen readers rely on an HTML semantics to create an allegation that the user can use to navigate more efficiently.
---
In this talk I am demoing how and screen reader uses, this increases and facilitate the beginning so the web.
---
You have headings menu that allows you to jump to a particular page. It lists all the headings on the patient allows you to choose which one you want to jump to and in addition you have other menus.
You have the header, navigation, search, main ,etc.
---
And you have the list menu which contains elements on the page. There's also the forms control menu which contains all the form controls on the page so that the user can also navigate and jump to them.
---
If the using is using semantic markup and proper sectioning elements, the user can move from one area of the page to another without having to go to the content in each section. And it is very important for them to be able to do so. But the document structure is defined by the document structure in your HTML so if you don't provide heading the document hierarchy for screen readers will be affected.
If you do not use a land market will not show up in the router and the user will not have the ability to jump to it.
This sounds pretty straightforward. HTML 5 provide sectioning elements and levels that are used to define the document structure similar to the visual hierarchy that users can get. Use these elements and you should be good to go but things are not always as simple as a sound. But if the design specs as they do not have a heading somewhere in the user has to infrastructures for visual elements for example, in a product I worked last year we had a couple of interesting scenarios.
---
I had a couple of places without headings associate with the midsection of the page, page listing a series of articles like this one had a description of top four sighted users and the list of articles and the sighted users can tell what the articles are about and how they relate to each other using the description of the content in the header.
---
I built a basic structure of the page but when I navigated the page using the router, I noticed two problems.
The headings problem including the list of all the headings with no context starting with a heading level 2 skipping to heading level 1. , There is no clear correlation between these headings that they belong to a specific section or title because the title is missing. And navigating using the landmark menu and this was in chrome I got all the main landmarks looking good except for the main content area.
---
We will need to read the entire paragraph before it announces that this is the main section. The fix in this case was simple: both medications were broken because the main section was missing a heading and since the design had no visible heading I added heading only exposed to screen readers and we will talk about hiding content in the next section but for now suffice it to say that this applies styles that highs this piece of text visually on making sure that is accessible by screen readers and adding these heading fixes both the headings and the landmarks menus in the rotor.
---
Adding a title to sections where one was missing was straightforward but then there were also instances where it looked like there was no heading but in reality there was one.
---
Similar to the other templates that also slightly different with the tag in category page templates. We had a header at the top, paragraph at the beginning of the page and then content in the sidebar and the main area containing a list of articles or resources sharing the same tag or category.
---
Looking at the design are visually divided the elements on the page into three parts.
Because I was familiar with how screening reader users navigate the page and because I made it a habit to always think about this from the semantics perspective I knew that navigating the page with the rotor using landmarks and headings something weird was going to happen and it is because of the little park here and heading inside of it.
If a user is navigating user headings this heading which open the headings list as resources tag with -- Incomplete. Tagge with what? Answering the question provided me with the first step to solve this.
---
Now that I have a complete heading was well what is this heading for? Heading creative petition the content will follow it but in this case it was not content, not on the sidebar. This heading describes the content on the right, in the main section and describes a list of articles these articles on the right are all the resources tagged generated. It should be part of this main section of the pace and since it is the main title of the page it should be marked up as such meeting should be a level I heading even if it is visually styled to look smaller like it H2 or H3.
---
With all that taking into consideration I visually separated the heading from the sidebar and the resulting markup looked something like this.
Somewhere in the code -- If I remember correctly -- Due to layout requirements are placed heading outside the main elements so I needed to let the screen readers know that the headings exist elsewhere. (indiscernible) -- The first paragraph, and now the page displays my landmarks properly and the screenreader associates a heading without landmark and the heading displays the proper structure and hierarchy to demonstrate the relationship between all the articles in the min area and categorizes under the generative tab.
---
Taking that into account and writing the underlying code the markup would've been much more different and much less accessible so the main takeaways are use HTML 5 landmarks, provide headings were needed, don't skip headings and if it looks small use the appropriate heading level in the HTML and make it smaller using CSS.
If it is visually hidden provide one for screen reader users.
---
80% of responders of screen readers will use regions navigate the can only do so you choose to use them instead of wrapping everything in this. You do not you semantic HTML elements you take away the user's ability to navigate the content, making it frustrating and accessible.
---
We mentioned earlier that the rotor contains many different menus, one for headings, landmarks and more and among them is it links menu and informed control menu and knowing how a screen reader user might advocate a page opens up the opportunity to improve the user experienced even more.
---
A common design in e-commerce websites is displaying a list of products on the page, each with its own add to cart button.
To demonstrate here is the Chilly's website using little bottles. Each bottle comes with its own ad to cart button and view link if you want to learn more about each bottle.
You get a list of all the form controls on the page including the add to cart buttons.
---
Quickly scanning these buttons you can tell that they provide very little value as there is no way to tell which product each button corresponds to. How do I know which button I want to go to and press if I do not know which product corresponds to? I do not want to add product to the cart that I don't want.
I bet you already guessed one way to improve the navigation, by adding screenreader only text. The solution could look something like this: you would add the product name in the middle of the button text so it says "add this particular bottle to cart." To include the product name and a button text string sonata form control menu displays the list of buttons and each button clearly indicates which bottle it is referring to and this is a very good solution for a screenreader using form controls but you do not want to do this because even though it improves the experience for some screenreader users it excludes users of other accessibility technologies and makes them unavailable to them.
---
A popular example of voice recognition software used to browse the web is Dragon NaturallySpeaking, software that allows you to use your computer and browse the web using voice commands. Such software is useful for a lot of people including but not limited to people with disabilities who can't use her hands for example power users that want to do things faster because voice dictation is faster than typing. Seeing in action gives you an idea of how it is used and how to improve our interface.
---
Level access to created a video demoing this, and I wish you could find it on YouTube. When the narrator is saying go to sleep and wake up he is pausing Dragon and reactivating it by telling it to sleep and wake up.
>> [Video]
>> Click full name.
Thomas Logan.
Press tab.
Go to sleep.
My work email address.
Click radio button.
One.
Click check box.
Pres tab, press tab.
Go to sleep.
When Dragon is an dictation mode I am able to speak any type of text and it will try to translate as best as it can. Wake up.
---
Please let me know when the North Carolina T-shirt becomes available. Period.
Press tab.
Now I've given focus to a custom control, and I can control this with a keyboard or a mouse and I will show you how all three options work.
(Video is captioned).
click next state, click previous state, Press right, press right.
Mouse grid.
nine.
One.
Four.
Six.
Six.
Click.
Go to sleep. Now you can see from those three options, the best option is having a nice name, using keyboard commands is a nice way to able to perform functions that do not have a logical speech command.
Lastly the mouse grid was used to demonstrate to you all how people have to use this technology to interact with software that has not been made accessible.
>> When a Dragon user wants to this is one of many reasons why visual labels are important in user interfaces so when we have a series of add to cart buttons, this is why adding text makes it inaccessible. The user will be telling Dragon to interact the button with a label that is different than what appears to be. But we can insert the product name into the button label, we can fix this experience for some people and breaking it up for other groups and challenges like this makes you scratch your head and think of alternative solutions and I like that.
---
As it turns out there is a middle ground here. We can still add the pregnant the button, improving the screen reader user experience without breaking the visible name of the button by appending it to the end of the button's name, instead of inserting in the middle.
---
By appending the text to the end the visible name is left intact and the rotor menu shows a list of the add to cart buttons; for voice control users when they say click add to cart, Dragon will label the buttons that start with add to cart, and label them with numbers like we saw in the video and then the user can speak out the number of the button that they want to clip. This works because voice commands works by saying the name of the input they want to interact with his lungs name is not broken in the markup.
A good rule of thumb is whenever adding additional information to a label it must come after what is visually present.
---
Knowing how voice control users navigate the web can also inspire more visual improvements or components. If a user needs to see a visible label to directly control, what about controls that do not have any visible labels? What about components that have less control such as dot navigation that we see in sliders?
--- Is the user wants to interact with these dot navigators, they are left with two other ways, voice commands to top of the control or the mouse grid which is the most hideous and least favorable option. The most attractive one is to add level controls but he that is not process is to show table and focus .
This image is a testimonial slider, in order to make the.navigation a little more accessible I added visible labels which are opposite to look at when the dots received keyboard focus, something similar to this.
---
Other visual elements that will be more accessible and associated with a visible label are icons or icon buttons to be more specific. Similar to the.navigation buttons if you cannot add a visible label (indiscernible) try to use I consider universally understandable other voice control users will have a hard time operating it.
---
And speaking of icon buttons I want to go deeper into other aspects of making it accessible.
I can buttons are great example to show different ways that we can process solution and will cover the different ways to hide and expose content while making sure it remains accessible to screen readers; knowing how to show in high counter with accessibility in mind is a fundamental piece of knowledge building accessible user interfaces but first you can inspect how a button or any other element will be exposed to a stranger using the browser's tools.
Here there's a simple button showing how it a deaf tool would work in Chrome. The most important buttons are accessible name and role. This tells the screen reader user that this is a button and what the label of the button is so they can interact with it. The deaf tools also shows you where they got the accessible name of the button from an in this example the text button shows the accessible name and the role is derived from the semantics element. It will not be exposed as a button anymore unless you add all the attributes to explicitly expose it.
---
If you expose it, you have to implement all the functionality using JavaScript, but why do you want to do that with the native button element provides that for free?
Using voice over Mac OS it would say "send message" button.
Pretty straightforward.
---
What name the screenreader use for a button when there is no text? We need text to label the body any to add that, we can provide labels for screen readers only, there is more than one way to expose buttons to screen readers.
---
We can hide content in CSS: Using inset 100%, opacity to 0 , Visibility hidden, display none.
These last two would make a completely inaccessible by hiding them from DOM and the accessibility tree.
---
The first attribute is the heading attribute; it is the HTML equivalent of CSS's display none. It is hidden from assistive technology.
(Speaker talking very fast, unable to capture all content.)
---
It is useful for hiding decorative or to picketed content for example decorative icons next to text.
Because they already have an accessible name for a button; of course that is assuming that the icon in the text label have the same meaning.
---
So for example if you have a menu button that has a label and a menu icon you can hide the action by setting its value to "true." I am also using the focusable attribute and sending it to "false".
---
(indiscernible)
---
So this can be used to hide content from screen readers while keeping it visually visible, why if you want to do the opposite?
---
Most of the times we need to provide text for screen readers only you want to hide the visually, for text the most common way to do so is to use Utility class.
---
The visually hidden class sometimes called screen only class, it's raises the element into one pixel square, hides the overflow and positions the element to remove any trace of it from the normal document flow. We can hide element visually only, from screen readers only from both.
Let's see how we can create accessible icon buttons.
---
Keep in mind that we want to have the buttons have an accessible name, let's see how we can approach them.
---
The first way we can create an accessible name for and I can button is by providing screenreader on text using the Sr-only text inside the button and the action becomes redundant so we hide it using (indiscernible). I have my button and my icon which is visible, my screenreader only text. Since the screenreader already has a label and already has the role implied from the button element, we hide it from screen readers.
We can use the text inside the button as an accessible name in the second approach is a very common and popular one.
---
Once again we have a button that contains our SVG I can but here we are providing the button name using aria-lable. This is used to provide an accessible element with a string of text and the string of text will be used as a name for the button.
---
A couple of things to note. He did not need to add the word button to the label because the screenreader will announce the role right after it's accessible name so this will be announced at the menu button. The content of the aria label will override the label of the content.
The contents inside the aria-label are not translatable. If a user uses a translation tool in order to translate the UI of your application there will not be able to translate the label of the button when it is provided inside the aria-label, something to keep in mind.
---
If you inspect this button in the deaf tools, you will see it is exposed again as a button with an accessible name derived from the aria-label.
---
The third technique combines the first and second one. You have text that you can expose the screen readers inside here. But you expose it using another aria attribute, aria-label by -- it derived from the contents of the element it points to not return values so in other words aria-label by take the idea of another element in this case -- (indiscernible) in the text content will be used as an accessible ---
This is not go to technique for adding an accessible name for adding names to icon buttons. (indiscernible)
The answer is simple even though it hides it from screen readers we can still expose them to the by referencing them inside the aria-labelby.
---
If we inspect this button in the deaf tools, we can see that it is exposed to the button with the accessible name derived from the label that the aria-label is pointing to.
They have their own rollbacks and compatibility issues but I have written an article in my blood in which I go over the details of these techniques that I highly recommend checking it out, so we covered the basics of hiding and exposing the content of screen readers that there are instances where these techniques fall short.
Specific when you find the need to hide an element in an attempt to create custom alternative styles, checkboxes and radio buttons are a good example of that and in the section I want to talk about checkboxes and the principles are covered will apply to pre-much every other interactive element in order to create a custom style check box we need to hide the needed check box and replace it with an image of the check box because we cannot stop the check accesses own but the image replacing the checkboxes at the end of the day are just an image, visual replacement of the real checkboxes so the user still need to check box to interact with.
Screenreader recognizes an image as an image; therefore when we hide the check box we still need to make sure it is exposed to screen readers. Typically when we use an SVG imager visually replace the check box the code would look something like this, and this is what I recommend.
I would have the label wrapping everything, (indiscernible).
---
Inside of my label I have my check box, I have my SVG that is going to replace it and the text label and at this point the check ox is still visible but before we hide it where going to apply some basic status of the SVG. Positioning and sizing into the text so that it scales with the text and then we style the background and checkmark and a default state and the check state; we also don't want to forget our focused also when the check box receives a focus we show an outline around the SVG check box and we use a sibling selector to apply focus styles to the SVG link.
---
Finally we need to hide the native checkmarks and this is the most important part. Which hiding technique would you choose for hiding the check box? Since we want to make sure that it remains accessible, we rule out all the rules to hide it from screen readers and is usually leaves us with the two most frequent answers. One, using the visually hidden utility class which sounds like the right solution because it hides the check box visually while still exposing it to screen readers. Two, move the check box off canvas and hide it using absolute positioning and this removes the check box in view not from the accessibility tree.
---
It is true that both of these techniques hide the check box visually and still would be accessible by the screenreader but neither are inclusive of users navigate by touch.
---
One of the ways is to explore by touch which means that a mobile screenreader can literally move their finger on the screen, on the page looking for interactive elements. The way you hide the check box determines whether touchscreen reader users will be able to find their not. As you can possibly imagine, hiding the check box off canvas will make it inaccessible to them they will be unable to find it is a drag your finger around. Similarly shrinking the check box will be difficult to find in touch, so while they can be good to hide static content it should not be used to hide interactive elements.
---
How do you hide interactive content? Hiding visually. Touch users can find it with haptics where they expect to find it; take the speaking this means remove the check box from the page level using position absolute so it does not take up any unwanted space visually and positioned it within the label making sure that it is position on top of the image that it visually is replacing.
---
You can resize it optionally and then visually hide it by making it transparent with opacity zero.
---
And finally since the native checkboxes still exposed to screen readers and I have a visible text label to go with it once again the SVG images redundant and relevant so finally we will hide it; and this is how you hide interactive elements accessibly. This applies to any item you need to hide in visually replace with something else.
For more detailed recap on this technique you can refer to the article I wrote about it on my blog.
---
There are many ways that people browse the web and too many to cover here in the short talk but there is one small tip I would like to cover, one small tip to optimize your experience for keyboard users so they too can navigate your content.
---
In addition to always ensuring that your interactive elements and components have proper styles you can use the tab index attribute in ARIA to create a more efficient experience for keyboard users. The faster the user can navigate the UI the better; the less tab steps, the faster they will get to where they need. Blogs and online magazines and other publications will normally display list of articles and post. A post entry has a typical anatomy normally consisting of a thumbnail, post title, author name, post tags, description and read more link. Typically the post tag and read more link to the same page which means the keyboard user tabbing will have to tab through three consecutive links to the same page. An example is the Forbes page, posts contain three links: thum nail, post -(indiscernible) -- so a user navigating using the keyboard practically needs to tab the same link three times in a row to continue navigating the next post and whatever content comes after. The more posts there are, the longer the tabbing journey will be and similarly the New York Times has post links with two links.
---
Medium is another example with five length for listing; if you use a keyboard a lot you are starting to note how redundant it is to tap for the simile multiple times in a row which a list of post is designed for such a structure, is usually optimized for sighted users or mouse users.
---
When the keyboard user needs to tap through the same link two or three times in a row, they are slow down because her journey becomes literally 200-300% longer than it could or should be. We can do better.
---
Depending on the post structure anatomy we could drastically reduce the experience.
You prevent the link being tabbed by using tab index = -1, and hide settling from screen readers using aria-hidden.
It looks like this: I have my article, the link, another link which is the title at another link which is read more link or read more icon.
I only want the heading or the title of the post to take me to the full article page so for the thumbnail and the read more links I add aria heading "true" and the tab to -1.
---
In the examples we saw the Post excerpts are short and there are no links. When there are several things within the title and read more link, the read more link should not be skipped because it improves the user experience. For example I recorded the process of tabbing through the Lea Verou's website.
---
Because there are quite a few links feelings after the post title each entry, the container reading link here is essential for the keyword experienced. The link is a shortcut in this case to the full article page and had not been there, or if it were skipped the user would have to go back to the full title to read it, counterproductive and this is an example of what you do not want to use a tab index in aria because it would worsen the user experience.
---
Each design comes with its own usability considerations any to be taken into account; in order to improve your experience you need to test the design using your keyboard and with real users if possible.
---
A good rule of thumb for similar cases is if you have multiple consecutive links to the same page there is a chance to improve keyboard navigation by skipping some of those links to reduce the number of tab stops. There is no one rule fits all.
---
As with previous sections, there is a detailed writeup about this case study on my blog.
---
People come in different colors, ages, sizes, backgrounds, abilities and disabilities and context. This diversity is beautiful, motivating and inspiring. As web designers and developers we have a chance to include everyone and we have a response ability to produce a web that does not include anyone and throughout the stock as you saw it takes little effort to create more inclusive, accessible expenses and I hope this talk has inspired you to approach building interfaces the more observing eye, more positive attitude and my curiosity to learn about your users
And inspiration to bill for the people of the World Wide Web.
Thank you.
>> RYAN BATEMAN:
Fantastic Sara, thank you for your time.
I have a number of questions.
If you like I am going to start at the top. The most popular question is,
what are some tools you would recommend to preview menus and landmarks on pages?
>> SARA:
I don
t have a favorite one, I use one of the machine which is called a voiceover.
Someone mentioned it also, only available for crown and as a Chrome extension.
>> RYAN BATEMAN:
It's an Edge extension as well.
>> SARA:
I personally prefer to use the screenreader and the rotoer. Just a couple of keystrokes.
>> RYAN BATEMAN:
You covered a lot of amazing content specific examples.
Are there SEO implications for using visual headaches?
>> SARA:
I heard a tip from a friend that SEO takes care of itself if you're putting great content, so if you're putting a great content you won't have to do a lot of stuff for SEO.
We are hiding them in a way that hides in visually but they are still there and still exposed to screen readers and Google search.
>> RYAN BATEMAN:
Thank you.
Myself working in marketing, if the screenreader can accurately crawl your site a Google bot probably also can.
>> SARA:
That's a good way to put it.
>> RYAN BATEMAN:
Next question I've got.
With the button labeled screenreader only text, is it better to append the screenreader text at the end or use ARIA to add more context from another element?
>> SARA:
With a button labeled screenreader only text?
I would talking about the label of the button?
It's better to append at the end?
It depends.
If you want the text to be part of the accessible name of the button, then you place it inside of a button, if you want it to be a description, I would probably not be using ARIA described by. An example is if you have an email address the label would be your email address and input. The screenreader will announce input, accessible name and after that a short pause followed by whatever you are referencing. ARIA described by ads and at a description that antitype of the element and the accessible name so you have a slightly larger description like what email should be.
With buttons you should not have long screens of text.
If I understand the question correctly that would be inside of the button and if I can answer another related question at this point, someone asked if it is better to add text inside of the button and then hide that element or add the label inside the ARIA label attribute. I would say use the child span inside of the button because with ARIA label, there are issues with translation, if it contains text the necklace the user may want to translate it to Spanish but the text inside
Will not always be translated so better to use actual text inside the button rather than visually having.
>> RYAN BATEMAN:
There are quite a few questions -- I'm not sure that you can answer these but we have specific questions about the difference in screenreader programs, one particular is asking what sort of experience do you have in working with others aside from voiceover on MAC like JAWS or NVDA? Can you help clarify maybe some of the differences when testing with them?
>> SARA:
I personally do not have any strange because I only have MAC machines, I do not have access to Windows machines. I rely on the expense of other people. My favorite reference is a friend called -- She does all the testing and shares incredible research. He works with real screenreader users and tests across myriads of screen readers and he shares his research and there are a lot of people working who are sharing their research, the results of their experiences and tests and me just like a lot of people, we rely on what those people share with us, at the not have experiences with other screen readers myself.
>> RYAN BATEMAN:
Maybe we can fit in one more question here.
What is the best way to describe clickable items for screen readers? Are there links? When using router buttons only for interactions?
>> SARA:
interactive items will either be a link or a button. The way to describe them is to first of all use the semantic elements so use button for buttons, links for links; if you absolutely have to deal with code that you did not write yourself, like a div that is behaving as a button then use ARIA attribute is to tell the screenreader that this is a button so would use role button, but when you do that you need to be aware that adding role button to a div does not add interactivity that the user expects on the button so you will need to use JavaScript to make sure that that div is clickable and the user can interact with it using the space and enter keys.
>> RYAN BATEMAN:
Thank you so much for your time Sara. We appreciate the massive amount of value and information you were able to give us today, sincerely appreciat it.
Thank you all for joining us.
