ARIA Spec for the Uninitiated - Gerard Cohen

[Music] again my name is gerard k cohen and i am currently the engineering manager for the accessibility experience team at twitter where you can reach me at gerard k cohen you can also check out my website at gerardk cohen dot me and uh for those that want to follow along the slides for this presentation are available online you can follow along at bit.ly so that's b as in boy i is in india t is in tom period l is in larry y as in yellow forward slash the number three v is in victor z is in zebra g is in george capital g as in george n as in nancy and the number zero so i'll leave that on the screen there for a second all right so uh this presentation is mostly for new users of arya and i'm basically going to be walking you through documentation and showing a few examples uh but even if you have been using arya for a while you might learn a few things so here's my agenda for today i'll start off first with the warning about the dangers of arya from there i'll do an introduction of the official arya standard pointing out important sections and then i'll get into the five rules of arya the last important resource i'll go over today is the aria authoring practices and i want to discuss their purpose and proper use at that point you should be pretty well introduced to aria and better equipped to create custom components so i want to first talk about the dangers of arya and why it's important to know and use it right so arya is a very powerful and essential is very powerful and essential to providing the level of dynamics available in today's web using aria incorrectly can cause some serious barriers for users of assistive technologies arya should be a last resort basically it's just a way to fill in gaps that html has so why is arya so troublesome well besides people not taking the time to learn it properly i would say one main reason is because arya's support varies there are a lot of hands in the pot by the time it reaches an assistive technology easier one thing to be aware of is that arya does not equal accessibility right so not to diminish the importance and impact of aria but it's only one part of the overall accessibility and usability of your work you're not accessible if all you did was just add aria even if it's the most amazing aria ever right so unfortunately arya is not always completely supported by both browsers and assistive technologies the same way and with the aria that is supported sometimes there are bugs in the implementation what's frustrating is that it's different across all browser and assistive technology combinations something may work great in one combination but not be implemented or function properly in another sometimes the implementations may break after originally working properly it's the same as you would expect with any of the other web technologies and unfortunately there are no media queries that you could query for support like css or the ability to test for support with js to provide a polyfill the only thing you could do is test your work and provide workarounds but you have to know what you're doing throwing arya out of problem is not always the solution to prove that point uh a survey of one million home pages by web aim in february of 2022 states that home pages with aria present uh present average 70 more detected errors than those without aria so the more that aria is used the more errors were found on the page so not only is throwing arya out of problem not a proper solution you could be making things worse so arya should only be used to fill in gaps that html does not provide it should only be used when necessary this is why there is a very popular sentiment in the community that no arya is better than bad re the point here is that if you don't know how to really use arya it's just better to leave it off thankfully you're here today and hopefully you'll learn enough to not contribute to making things worse so if arya is dangerous why am i here talking about it so personally i think that arya has a bad rap and it might be a controversial statement to some but i think it's excessively vilified and i can certainly understand why a lot of the negative sentiment is definitely warranted i can't deny that it can be easily misunderstood and abused and can do some serious damage to assistive technology users i think it's much easier to just say don't use it than it is to properly explain it and learn it but that's not really going to help anyone at a certain point html alone is not enough and you'll need to reach for arya just like anything else it's not perfect by any means but you shouldn't be overly afraid of it and you shouldn't avoid it you definitely need to respect arya and i recommend that you take the time to learn and understand it so with that being said let's get into the documentation so the very first resource that i want to expose you to is the official aria standard itself normally visiting the official standard or spec for any kind of web technology is reserved for the extremely academic types and most of you have probably never really read the official ecmascript standard but i want you to treat the official aria standard as an api guide to get the most up-to-date information on available options if you want to know what something means i urge you to come here to the official aria standard first so you can always get to the latest version of the standard by going to www.w3 forward slash t r forward slash y that's w-a-i-a-r-i-a which i have on the screen now the first thing you'll learn here is that arya actually stands for accessible rich internet applications which is kind of a throwback to like really old internet terms as of today the latest version of the aria standard is 1.1 so make sure you bookmark this if you want to do aria well if you want to do aria right you'll be referencing this a lot um the spec for aria 1.2 is further along in the spec uh standard process uh so it doesn't hurt to check that out every once in a while um but when it comes to the spec i don't expect you to read the whole thing but there are a couple of sections that i want to point out to you right now that will serve as the basis for everything you will do related to aria from now on the first section that i want to point out is on the screen now uh it's section 5.3 which is the categorization of roles this section lists the available roles that aria provides what are roles well roles are how you provide semantics to elements and semantics are extremely important to accessibility so what exactly are semantics well semantics basically express what something is and once you know what something is then you know how to use it and what the expected result will be for example if i was to hand you an object and tell you it's a fork you'll most likely know what it is and how it's to be used so aria roles provide semantics and the aria 1.1 standard provides

70 usable roles that's the total list you cannot make up your own roles so let me repeat that you cannot make up your own rule of these 70 roles in version 1.1 only 29 of them are interactive widget roles and i'm going to focus on those right now these interactive roles are defined in section 5.3.2 widget roles and can be broken down into two groups standalone and composite first standalone widgets either operate on their own or exist to be part of a composite widget and there are 20 standalone widget roles that i'm highlighting on the screen now some of which may be familiar to you already like button checkbox or link again when it comes to standalone widget roles this is the complete set you cannot make up your own the next group of composite widget roles uh the next group are composite widget roles and these are essentially parent roles or containers for other standalone widget roles and there is a very strict hierarchy when it comes to composite widgets these have to be composed of very specific standalone roles and often in a very particular order in most cases you cannot pick and choose which roles you use to compose a widget since some standalone rules can only exist as a child or nested in one of these nine composite widget roles that i have highlighted on the screen here let me repeat that there is a very strict parent-child relationship between certain roles so some roles can only be used as a child of a specific composite role and this is very extremely extremely important to understand especially with how easy certain ui libraries make it to use or to reuse components and render wherever necessary so be very careful about how you nest components and roles because you could be breaking your well intended accessibility if you don't respect the parent-child relationship of roles detailed information on how to use roles and how to apply standalone versus composite roles can be found in the definitions for each role diving into the definition of roles they all follow the same format so on the screen now i'm going to be using the button roll definitions as an example each role provides a definition and information on usage in this case for example a button is defined as an input that allows for user triggered actions when clicked or pressed in addition to this description helpful usage guidelines are also included for button this is information i'm highlighting that describes how buttons support aria pressed and is used to create toggle buttons take this time to read this information because it always provides additional information that may not be gleaned from the general template for definitions after the definition of each role we have a table of characteristics that will further help you in determining what you need to include or what is supported when using a particular role the first section to point out is the base concept section not all roles will have this but this is your first clue that the semantics provided by this role can be provided by an equivalent html element for the aria role of button the base concept is an html button when you see this i highly recommend that you move on to using the html equivalent that is listed here instead of the aria rule after the base concept uh after the base concept is this finite list of supported and inherited states of properties i'll go over states and properties in a little bit but the important thing to remember uh to remember here is that there are only state these are the only states and properties that can be used on this rule for button there are only two explicitly supported states that's aria expanded and aria pressed after the explicit list of supported states and properties is the inherited states and properties these are all also supported by the role but they are as described inherited from a superclash rule so this collection of supported and inherited states and properties are the only states and properties that this role supports if you apply or state if you apply a state or a property that is not on this list of supported states and properties then you're breaking accessibility the next set of information has to do with the accessible name letting you know if an accessible name is required and what that accessible name is calculated from accessible names for interactive controls especially are extremely important because they identify a widget this is how assistive technology users know what they're interacting with in the case of a button the accessible name comes from the contents of the button speaking of the contents pay attention to this last item here which is the children presentational section this is another clue to let you know what is allowed to nest inside of this element if this is true it basically means that content inside of this is stripped of any semantics so if you nested links inside of a button or headings like i recently did you're breaking accessibility now a few more important sections i want to point out related to specific composite roles if you remember when talking about composite roles i told you that composite roles have a very specific parent-child hierarchy the role definitions give you this information and it's listed in required own elements in the section of required own elements of the characteristics table essentially these are the required child role elements for this role and not all roles will have this section in this case uh on the screen i'm displaying the menu role definition the required own elements here let you know that the menu role will require at least one instance of an element with one of these roles again these are children that will be expected for this role and if you're missing any of these elements listed in the required own elements you're breaking accessibility on the flip side you also get information on the required parent role for a particular element and this is documented in the required context role section in the table of characteristics and on the screen right now i'm showing the menu item world definition as an example and the required parent role for menu item is one of group menu or menu bar if you are using the menu item role and it is not nested nested in any one of these roles you're breaking accessibility so that's a very high level overview of how the specif how to spec to find roles uh how you can use this information when specifying roles for your aria components and one thing i want to make you aware of when using roles roles do not provide interaction they simply just describe what something is but do not provide the expected behavior you need to provide the interaction and once you tell what something uh once you tell someone what something is they'll know how to use it so you need to provide the expected interaction it's important to know that certain roles can change input modes for various assistive technologies so specific interactions are expected for example a specific role may change what is expected of the arrow keys and you need to provide that when you don't provide those interactions then you're breaking the contract established by the role so it's the example that i like to use here if you ask me for a screwdriver and i hand you a four along with providing semantics by way of roles aria also provides states and properties to further describe interfaces to assistive technologies and as of aria 1.1 there are a total of 48 states and properties so let's take a look at these available states and properties back to the official aria standard at section 6.6 which is the definition of states and properties all the available states and properties with their available values are listed here so just like the roles you cannot make up your own states and properties or provide your own values you can only use these 48.

again you cannot make up your own states and properties and along with not being able to make up your own there are rules about which states and properties you can't apply to specific roles some states and properties are required on certain roles and some states and properties are not supported or allowed on other rules looking at arya expanded on the screen as an example of definitions for a state of or or property you'll see that the format is the same as role definitions it basically starts off with a description and some usage guidelines and just like roles each state and property definition includes a table of characteristics here's the used in roles section and we see all the roles that support this particular state as a confirmation i see that button is listed that matches the supported states we saw for button earlier so if you use this state on a roll that is not listed here then you are breaking accessibility after the characteristics table you have a table documenting the available values for the state for example aria expanded accepts a true or false value where true means it is expanded and false means it is collapsed these are the only values that you can use for this state if you use something other than the values listed here you're breaking accessibility so understanding roles states and properties understanding the relationships between them and knowing when and where to apply them is everything for proper aria usage what i've shown you here is how to use the specs when creating your custom components again this documentation is replete with everything you need to understand how things work together and that's a big part of understanding aria but there's still a few more resources that i want to go over that will complete your initiation into aria so when it comes to arya there are five very well established rules that you need to be aware of and these high level level rules will always guide you in making the right decision when you're developing your own aria widgets the first rule of aria might as well be the only rule because it is repeated so often if you have already started on your journey in arya then you may have heard this one already the first rule is don't use arya now this may remind you of some sort of fight club rule and arya can cause a lot of fights definitely but if you're confused by this rule it's because it's not totally accurate the actual this is actually an incomplete rule and and statement that we use all the time the entire rule to be aware of is don't use arya if you can use html instead the second part is almost always left off but it is really important as i mentioned in the overview of the aria standard arya is used to describe rigid widget role semantics and state and a lot of this is covered by existing html elements and properties so instead of role equals banner you should be using the header tag install instead of role equals complementary use the aside tag role of button is the same as the button tag just like role of link is the same as the a or anchor tag and instead of using role equals navigation just use the nav tag as i mentioned earlier if there is an html equivalent to an aria role you should always prioritize using html html can provide semantics focusability and interaction and if you can use the html counterpart first and it's supported by browsers and assistive technologies then you're better off just using the html as it will provide all the same properties as aria while providing a more stable experience simply by using the right html element you get semantics the focus ability and interaction already built in it's less work for you and less code and less of a surface area for bugs in the experience this is exactly why accessibility professionals stress learning html so much it does a lot of the heavy lifting for you and i know it's easier than it sounds since is a lot of html elements to choose from it could be hard to know when to use html versus aria so i'm currently working on a period periodic table of semantics so on the screen i i have an example of the uh this periodic table of semantics and it lists every html element available and it matches to an aria rule so if you need to provide semantics you can easily find out if there is an html element you can use and if it's not then you could fill in the gap using aria i'm still working on this and i've been working on it for a long time but the day that all the data is there with links to each of the official specs and you can find this uh this periodic table of semantics at um bit dot l y forward slash the number two i as in india capital m as in mary capital k is in king the number one lowercase k lowercase o is an oscar second rule of aria uh is don't change native semantics if you're being responsible and using html first you have to make sure that you don't use arya to replace the semantics of that native element you see when you use an aria role you are explicitly setting the semantics of the element the aria role takes precedence over the html so let me show you an example let's say your sider application has a collapse menu and you're losing you're using a link because it's easy to style and also natively provides focus ability which you heard was good for accessibility you provide a click handler handler to prevent the default behavior of making the page jump when the link is used and then you display your menu at some point you learn that links are meant for navigation only and you should really use a button for this but you don't want to have to modify or markup your markup or your css and you also just learned about aria roles and how they provide some magics so you decide to just add the role of button to this anchor tag now this menu is community communicated to assistive technologies as a button and you're happy so what is the problem with adding the role in this way well as you've already learned roles specify semantics and semantics are a contract the element needs to be behave as expected for the role but links don't act the same as buttons see links are activated using the enter key and buttons are activated using the space key you've told the user that this is a button and they will try to use the space key but nothing will happen you've broken the contract so to fix this you decide to add additional javascript to restore the contract and now technically in the assistive technology might smooth over the usage of space versus enter but that really shouldn't change the guidance here at this point considering all the work you had to do to fix that situation hopefully you realize that would have been easier to just use a button again if you use html as intended the platform will provide a lot for you including semantics and interaction you then use arya to fill in the gaps as necessary hopefully the third rule of aria should be familiar to you already basically all interactive aria roles need to be operable by keyboard if functionality is provided via a mouse touch or any other method of input it also needs to be available by keyboard this is important in fulfilling the contract of semantics keyboard support is absolutely fundamental for accessibility support ensuring keyboard support will get you a long way with other input modalities as well like game controllers for example the reason for that is because a lot of additional input modalities actually use uh keyboard apis under the hood so if you can support keyboards very well it leaves you open to supporting any other type of input modalities the fourth rule of arya is don't use role equals presentation or a hard aria hidden true on visible focus elements now to break this down the role of presentation is a very special role it basically removes the semantics of an element if you do this to an interactive or focusable element then an assistive technology user will not know what it is or how to use it and this could be a serious barrier arya hidden is an aria state that effectively hides the element from assistive technology users so if you remember me saying arya just described things it does not affect appearance or functionality the way html attributes might when you use aria hidden true on an element it's still rendered and visible on the screen but doing this on a visible interactive element hides that element which can again create a serious barrier to your users proper ways to hide elements is a completely separate conversation but for now just know that role equals presentation and aria hidden true can be very dangerous if not fully understood and supported properly the fifth and last rule of aria is that all interactive elements must have an accessible name and why is this important well if semantics or role gives you the type then accessible name tells you what and not only is it this important for screen reader and braille users it's also important for voice recognition user voice recognition users to be able to identify and interact with controls on a page so make sure that all interactive elements have an accessible name the five rules of arya are documented here on the w3 site at www.w3.org forward slash tr forward slash aria dash in dash html and you can read up on more information and examples there's some other really good information documented on this page and i encourage you to check it out to learn more so up to this point i've gone over a lot of documentation and principles and now it's time to get into some specific examples of implementing aria and when it comes to creating custom components you don't always have to start from scratch there are some established examples you can use to start off with another important resource that i want to discuss here are the official aria authoring practices and this resource is often referred to as an example of proper aria implementation for various widgets the authoring practices are available at www.w3.org forward slash tr forward slash y that's w a i aria dash practices and they demonstrate about 29 different widgets and patterns some are essentially aria recreations of html elements like button checkbox but some of them are interactive interactive widgets that are only available via aria like tabs i'm going to use the accordion as an example now each pattern starts off with some information about the general purpose and usage which can include very variations on the pattern i'm going to skip over the example for right now and go over to the keyboard interaction section included with each pattern is the expected keyboard interaction which describes each interactive element with the expected keys to implement and the expected result of activating those keys for example with the accordion when focus is on an accordion header enter or space should essentially toggle whether or not the accordion is expanded expectations for tab and shift tab as well as optional controls like up and down arrows or home or and end are also included after the keyboard section is a section that lists all the necessary aria roles states and properties for the pattern everything you need to know in terms of implementing this pattern is listed here now to experience this in real life let's go back to the example that is provided here all of the examples follow the same outline they start off with some links at the top a brief introduction uh on the examples being demonstrated and how the pattern is being implemented and i'll go back to these links in a bit after that is a live working implementation of the pattern that you can play with in test following that is keyboard support that is implemented in this specific example and again this breaks down all the expected keys that are implemented and expected and the expected interactions and then there's more uh a detailed description a more detailed description of the roles states and properties and the tab index used in the pattern this is like a mapping of html elements to aria rules and attributes used in the example to round out the example are links to the css and javascript files and the markup being used so maybe you're thinking about skipping the rest of this presentation and just copying the examples here since everything is done already well not so fast right these authoring practices are often used in a way that are not originally intended and often used incorrectly let me point out some important notices in the documentation in the very beginning i talked about these links at the top and i want to point out some things mentioned in the browser and assistive technology support page it states testing assistive technology interoperability is essential before using code from this guide in production because the purpose of this guide is to illustrate appropriate use of aria 1.1

as defined in the aria specification the design patterns reference examples and sample code intentionally do not describe and implement coding techniques for working around problems caused by gaps in support for aria 1.1 in browsers and assistive technologies it is thus advisable to test implementations thoroughly with each browser and assistive technology combination that is real valid that is relevant within a target audience it goes on to say except in cases where the aria working group and other contributors have overlooked an error examples in this guide do not function well examples in this guide that do not function well in a particular browser or with a specific assistive technology are demonstrating browser or assistive technology bugs browser and assistive technology developers can best utilize code in this guide to help assess the quality of their support for aria 1.1 and that's from the aria authoring practices document section 2.2 browser

and assistive technology support with some added emphasis by me so what does this all mean what this is saying is that they don't provide any guidance as how to work around bugs in browsers or assistive technology and these guides provide the state at which they would like things to be supported it's a testing tool basically for browsers and at vendors to help beef up support if something is not working the truth of the matter is that aria is only a spec and there's no guarantee that browser vendors or assistive technologies are going to support all the roles states and properties just the same way building codes do not always guarantee that something is built properly at the code because of this they advise testing everything before using one more thing i want to point out here currently this guy does not include which examples are compatible with mobile browsers or touch interfaces while some of the examples include specific features that enhance mobile and touch support some aria features are not supported in any mobile browser in addition there is not yet a standardized approach for providing touch interactions that work across mobile browsers and that's from the aria authoring practices document section 2.3 mobile and touch support and this is basically an acknowledgement that these patterns and the aria used to build them may not be supported by mobile browsers in fact the design patterns did not even really take mobile and touch into consideration this is obviously future work to be done now up until recently these notices were tucked away in the spec documentation but now all the examples have recently added this callout here that i'm highly on highlighting on the screen titled important note about use of this example if you expand this content you'll see the information that i just read is summarized so take notice of this now i see a lot of component libraries advertise they are accessible because they implement the author the aria authoring practices just be aware that it doesn't always guarantee accessibility things absolutely must be tested so what are you supposed to do i'm not telling you that you can use these patterns you can certainly use them as a basis for your widgets but you shouldn't use them as is the point of all this is test test test everything that you do and not just on your own hopefully with real users you'll discover some inconsistencies and you will be expected to fill in those gaps on your own that's why it's important to know and understand aria not just copy and paste these patterns the aria spec calls this out explicitly in the testing practices and tools section by saying the accessibility of interactive content cannot be conferred by static checks alone developers of interactive content should test for device independent access to widgets and applications and should verify accessibility api access to all content and changes during user interaction and this is from the author of the aria authoring practices document section 1.5.2 for testing practices and tools so just another prompt to make sure that you're actually testing with assistive technologies and not just relying on the inclusion of arya to ensure accessibility another thing i want to mention is that since this is basically an aria testbed a lot of times they will excessively use aria roles and properties that are perfectly available via html this is not a suggestion or example to always use aria instead of html but in order to test aria they actually have to use the aria so again i'm not saying you shouldn't use this resource i'm just emphasizing that you need to test everything yourself you should definitely follow the keyboard interaction and start with the roles and properties demonstrated but experiment with falling back to using html first and then make sure you test everything with assistive technologies so in summary don't be afraid to use arya familiarize yourself with the specs and learn how to use them properly use only what is needed to fill in html gaps mastering aria is not just about how to use it but more importantly when not to use it and no matter what you do make sure you test everything so again arya can be dangerous if you don't know what you're doing remember arya is better than no uh no arya is better than bad arya but at least now you know how to use the spec to understand how everything works together aria is finite there are only 70 roles and 48 states and properties you cannot make up your own there are also strict rules around parent-child relationships for roles again use the standards to understand relationships aria only describes content via roles states or properties it does not magically add functionality that is up to you keep in mind that adding aria roles may change assistive technology input modes and usage of certain keys will be expected you need to provide that interaction that's why it's best to learn html and prioritize it whenever possible use html over aria will almost always give you a more reliable experience i also showed you that the off the the aria authoring practices uh with a caveat that they are not meant to be copy and pasted the primary purpose of those examples are to provide a testbed to browser and assistive technology vendors to provide better aria support there's still a good reference to start but they're not an end ultimately you need to test everything for proper support and functionality don't be afraid of arya familiarize yourself with the specs and learn how to use them properly use only what is needed to fill in html gaps and remember mastering aria is not just about how you use it but more importantly when not to use it and at this point you can consider yourself initiated but this is only the beginning before i go i just want to take this opportunity to shamelessly plug plug and quickly let you know that i do have some accessibility courses available on the pluralsight learning platform which are part of the developing websites for accessibility path so if you want to learn more about accessibility uh specifically with that engineering focus you can check out my courses meeting web accessibility guidelines which includes aria 2.1 introduction to develop custom components with aria which is basically the advanced version of this presentation and lastly accessibility testing and screen reader use and if you're interested in learning more from me you can check these out over at pluralsight and with that i want to say thank you for attending and thank you to tech access oklahoma for allowing me to speak today i hope you can feel more comfortable about arya again these slides are available at bit.ly number three v is in victor z is in zebra g is in george capital d is in george n as in nancy zero and if you have any questions or comments or feedback you can reach me at gerrardkaycohen on twitter so we have some time for some questions and if not have a great rest of the day all right hi gerard uh hello so um yeah we've got a couple of good questions here in the in the q a and so um ashley clayton asks uh so basically you don't want to make up your own aria and you want to try to follow the documentation to the letter correct yes so um you definitely as i mentioned multiple times you cannot make up your own aria roles or states and properties you have to be very careful about how you apply states and properties to specific roles and you also have to respect the the parent child hierarchy so definitely follow along uh with the spec itself the the spec and the table of characteristics that i that i highlighted is your best resource to find out where to start after that you want to you want to actually test with with assistive technologies to make sure that things work the way you expect them to and the way your users expect them to right and that actually kind of leads into the next question michelle asks do you have any recommendations for the best assistive tech to use to test with that's uh there's a short answer and a a long answer the short answer is you know uh start with the platform that you have in front of you if you're on windows um test with um you know with the jaws uh screen reader uh and specifically you know try to stick with the browsers like chrome or microsoft edge which you know under the hood are the same jaws obviously there's a cost associated with it so you can also use nvda i recommend testing that using firefox and you can also jump over to chrome to figure out any inconsistencies if you're on a mobile device obviously mobile devices on ios you have voice over to test with and on uh an android you have talk back so use any combination of those um also on mac as well you have voice over that i suggest testing specifically with safari um you may run into issues if you're using safari and testing on chrome or any other browser so i recommend sticking with uh safari um that will give you the best support um so any of those uh in combination is great to start if you can do as many of those as possible that's really the best thing because again support for uh arya depends on the combination that you're using so um do as much as you can using any of those combinations great great uh melissa asks using browser stack currently for testing but what are some good options for implementing testing with with at that kind of uh answered that a little bit already but do you have anything else to add to that yeah um so obviously if you don't have all those platforms and and this is the technologies that i just mentioned uh which a lot of people just don't have access to i understand if you want to do a really good job again start with the platform that you have and try to use the actual platform and the the assistive technology for that browser uh and platform combination after that there's actually um there's a really cool website that i've used and this is not a direct endorsement i'm not affiliated with them but i believe it's assistive labs um actually gives you the ability to virtually test in those combinations so they do have access to a windows machine that you can test nvda you know with firefox um if you have a valid license for jaws you can also test jaws in that virtual environment uh and i do believe that they they have uh some other platforms as well so if you're in the virtual side of things you can uh you can try out uh assistive labs which is browser-based obviously a lot of times since my main development machine is my mac what i do is actually have so i'm able to test on my mac i'm able to test safari and voiceover because that's built in but i also use a virtual pc to install you know just a running version of windows and with that i will um test jaws with chrome or microsoft edge and then also nvda with firefox which is an option as well um but one thing you have to be careful with in that virtual uh that virtual environment is that the keyboard uh keyboard interaction changes when you go from your host machine into the to the virtualized pc um so you may have to test uh with some different uh keyboard settings um and uh if you have if you want more information about that just reach out to me on on twitter and i can help you with that great uh carrie asks what is the most common mistake you see with uh improper use of aria oh wow um most common there's there's a few using incorrect roles and then using uh nessing roles improperly are probably the biggest things so you know i briefly mentioned uh with a lot of ui libraries that make it easy to render things wherever you need to a lot of times what i'll see someone uh you know with specific libraries do is maybe they they render a menu um and uh then inside of the menu that maybe they they use another library component to render maybe a modal or a balloon or something like that um that looks visually like it's not attached to that menu at all but actually because of the way it was implemented it renders within for example that menu role and like i said uh earlier is you have to really respect the child the parent-child hierarchy of the way your nesting roles so that's probably one of the biggest problems uh most common that i see other than that is just using the wrong roles and making up making up roles is another thing and then um i've seen a role equals hamburger menu which doesn't exist a lot of people you know what does that even mean um so though i'd say off the top of my head those are the three most common uh aria issues great um jeanette asks is aria better used for mobile app support rather than websites uh consumed on a computer uh no so there's always going to be better support on uh you know browser-based uh implementations on you know a full-blown machine so either a laptop or you know a desktop computer and that's just because there's history there right like those things have existed for what 25 years maybe i think the web's like 25 years uh maybe a couple years older so the support is always going to be better there um mobile usage mobile browsers again we're we're we're still relatively new in that area um so the support isn't going to be as great but um that's uh that's a level of specificity that i don't think you should really worry about to be honest um you start with what you can and use what is you know what is expected based on the specs and then you'll find out that the the you know mobile mobile screen readers and mobile browsers for the most part work in describing things it usually comes around the problems with the mobile browsers uh usually happens around interactions because it's very hard to translate very specific keyboard interactions to swipes and even just the you know listening for swipe events and translating that into actions is very difficult on mobile platforms so um but again don't uh don't split hairs over you know should i use aria only for mobile versus you know desktop computer web just just use what you can when you can and you'll get some pretty good support anyways great um and so along those same lines melissa was wondering if uh if you expect mobile support for arya to to change sooner than later yeah uh hopefully sooner uh there's obviously it's recognizing the communion as a big gap not only within arya but also within wic the web content accessibility guidelines as well um you know again web content accessibility guidelines is like 20 years old right so the name even is a throwback to you know past times with web content accessibility but um definitely there's work being done every day to better implement uh support for for mobile applications and browsers okay and uh looks like we have just one final question here uh you know encourage people to go ahead and send in additional questions if they have any uh but the kristin asks where in the development cycle do you add or assess for arya when writing the html in design i'll give kind of a generic response uh that relates to just accessibility in general a lot of times we like to say that the the best time to implement accessibility is at the beginning uh the next best time is right now um so for me personally just because i've been doing it for so long it's not because i'm like a genius i just have muscle memory of doing it wrong for so many years and trying to get it right is i just do it as i'm as i'm coding like it's just part of muscle memory for when i'm writing tags uh ideally um you know it's uh overall in a larger sense uh it's it's a shared responsibility um so hopefully your designs that you're getting if you're working with the designer hopefully they're um they provide the intentions for you uh in the designs rather than just providing you know you know pixels uh arranged in a certain way um so hopefully they'll they'll give you some clues as to you know this is a button this is a link this is a menu and you could translate that into the implementation or if you have a design system for example uh maybe that's that stuff's already built in for you uh but really it's kind of a shared responsibility uh if we're focusing just on engineering uh and development like just do it at the beginning uh because trying to add it and this is the same for accessibility in general but trying to add it after the fact may cause you some some some heartache so as early as possible and as often as possible you want to do it uh yeah it looks like we have one one final question from brent and he asks with the momentum behind web 3 and the metaverse have you seen movement toward accessibility in that arena and if so does arya have a place there um that's a great question uh historically cutting edge technologies usually usually leaves out accessibility there are some people that are working really hard in the vr space to make sure it's included because vr can be an amazing assistive technology and can really open up a lot of things for people with disabilities so there are people that are working to to make sure that that's included as as everything is being built um web3 is still very early in a lot of different ways um that i don't think they're really thinking of of accessibility it's it's more kind of uh you know architecture and and you show me a proper web 3 implementation and and i'll tell you if it's successful or not but if you're in that space and you're excited about those technologies um take what you know here and try to apply it there so don't don't wait for other people to do it because nobody's really doing it right now to be honest so we need people like yourself brent that are interested in those technologies and also interested in accessibility to bridge the gap and make sure that we're not left behind because one of the one of the problems that we have why accessibility is so horribly supported is because they're it's not thought of at the beginning so a lot of times decisions are made 10 years ago that make it absolutely impossible to add accessibility or add accessibility without trying to rip out everything that was done before so again the best time to do it is at the beginning um so just keep that in mind as you're you know working on those technologies right okay it looks like we had a one one additional question come in um but you know i also want to respect everyone's time and give everybody a break uh and so just kind of as a final uh final thing here marcia was wondering if you have any additional resources or course suggestions uh for learning aria yeah if you thank you marcia for the question i mean if you could stand the technical language uh like i said the spec is the best place and the first place you should go to um everything is listed there in the official spec for each role and property um go back over the the slides to to give you you know the the cues uh and sections to pay attention to if you're looking for more uh specific instructional material i'd you know i'd have to be a little proud and say that um i'm very happy about the course that i have on pluralsight for creating custom components with arya um i really again that's more of an advanced version of the presentation i gave you today here where i really go in depth about the specs and then also go through specific examples in creating a custom component and showing you from from start to finish you know you have this idea of something you want to build let me check the spec to see how i can build it and then just follow along um so you know i would i would suggest you check that out on pluralsight um pluralsight for you know obviously it's it's a it's a it's a commercial learning platform they do provide a 10-day uh 10-day trial for free um which 10 days you know if you're if you're dedicated is more than enough time to get through the the three courses that i have there um on the short and uh they're an hour and a half on the long end they're three hours um so you know within 10 days if you're if you're dedicated you could probably get through those within the free trial period [Music] you

2023-02-15 10:21

Other news