| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Thanks for your interest in The Question! Sign up to participate in future questions here. This file is the raw data from Episode 14, deep dive hosted on March 14, 2024 with Ben Callahan and Daniel Henderson-Ede. There are 77 answers. The question this week was: ----- Daniel and I were chatting that many organizations are finally realizing just how critical digital accessibility is for the needs of millions of disabled people, and the long-term health of their business. It’s refreshing. And yet, it’s one thing to acknowledge this and another to to do something about it. It turns out that thinking about accessibility at the component level gives you a great start in offering more inclusive experiences across your digital products. In fact, one of the most compelling stories for internally selling design systems has become accessibility. However, once you’ve made the case for the impact a design system can have on accessibility in your products, how do you actually live up to that promise? That’s what we’re digging into this week... With all of this as context, here is The Question for this week: How accessible do you feel your components are? What is the process you use (or wish you used) to ensure your components are accessible for all users? | |||||||||||||||||||||||||
2 | Question 1: How accessible do you feel your components are? | Question 2: What is the process you use (or wish you used) to ensure your components are accessible for all users? | ||||||||||||||||||||||||
3 | 5 | While working on DS, we cannot cross brand guidelines. This is a more fundamental issue. A simple example: Our brand color has very low contrast and is used everywhere on our platforms as the main call-to-action. DS team cannot change it since it represents our brand! | ||||||||||||||||||||||||
4 | 8 | We have an internal Accessibility Specialist sat in the DS team. They audit the already in-service components, and inform the new components development process. They also help ensure that components are used correctly in-situe by subscribing teams. But that is the job of more than just one person - we should have a whole teams, potentially embedded within key squads, to ensure accessibility. We also operate a Slack channel, where individuals can bring their queries to our specialist, but that's a band-aid over deep wound - most of the problems are things that individual designers are completely unaware of, and for engineering, there's very little oversight other than trusting the knowledge of the individual squad developers, which is often sadly lacking. | ||||||||||||||||||||||||
5 | 6 | Accessibility acceptance criteria for components, that is checked every time when making changes/introducing new components. | ||||||||||||||||||||||||
6 | 8 | We use Storybook's capability of testing accessibility and unit testing including people with vision disabilities | ||||||||||||||||||||||||
7 | 5 | Accessibility testing is not something that is really taken into account at our org even though we're expected to be comply with WCAG AA standards. There's no experts on accessibility available (at least that I know of) and accessibility is still an after thought. As a design system team that doesn't have an accessibility specialist, we always run into that knowledge gap when it comes to accessibility. We claim our component in accessible, because we looked at color contrast, we looked at keyboard navigation, we test with a screenreader (not all of them and not on every browser/OS).. We looked at some WCAG criteria and copy best practices from other design systems... But how can we be sure that we've covered everything? We just carefully push out our components and hope for the best. I really wish our components would go through an extensive checklist of testing to make sure we've covered all use cases, instead of just checking the accessibility feature in Storybook for any violations. More often than not, accessibility can't be fully baked in to a component. I often find teams expect a component from the design system to be accessible out of the box, but that component still needs to be configured in the right way to ensure that it's actually accessible when used in the final product interface. Trying to make sure that everyone knows how to do that is a job, but without a specialist taking on that job, we're just as pressed for time doing things that we have more knowledge of. | ||||||||||||||||||||||||
8 | 9 | We have SMEs within our Digital Accessibility Center evaluate our components while they are in beta in order to meet WCAG 2.0 standards. | ||||||||||||||||||||||||
9 | 5 | Currently piloting: a11y toolkit where we add on notes and stamps | ||||||||||||||||||||||||
10 | 8 | Comparing to WCAG standards, using accepted best practices, have a vendor we consult with | ||||||||||||||||||||||||
11 | 8 | We have an accessibility team within the design org, and 2 of those accessibility specialists are fully dedicated to the DS. Their review is one of the conditions for releasing anything. They are also auditing all past components and patterns to ensure those are fully accessible too. Other accessibility specialists who work with the product design teams review the accessibility of the complete UI, and anything that is flagged as an accessibility bug caused by a DS component is sent back to our team. | ||||||||||||||||||||||||
12 | 8 | - Follow WCAG standards for things like color contrast & touch targets when design spec-ing new components - Outline A11y concerns when creating RFC for new components - Test for A11y via storybook automated testing - Test with a screenreader (e.g. voiceover) - Document WCAG standards that apply to each component as part of component documentation - Prioritize A11y bug reports | ||||||||||||||||||||||||
13 | 9 | From a content perspective, we include WCAG guidance for each component. | ||||||||||||||||||||||||
14 | 5 | In a large company, the process we used was to propose a component, have that component vetted by an official accessibility team (which included users who were blind or relied on accessible tech daily), then when the component was nearing launch the accessibility team would be looped back in. The accessibility team also was constantly evangelizing and consulting with other teams, and doing presentations to designers and engineers. This took a lot of resources. In smaller orgs, it has been mostly the design managers promoting accessibility even if they were not experts. As a design systems manager/lead, I was often the sole voice promoting accessible strategies and writing them down in docs. | ||||||||||||||||||||||||
15 | 9 | After designed, the components are given a11y annotations in Figma to define various requirements, i.e. which HTML tags to use, aria attributes, etc. All components are also reviewed by Accessibility Engineering after development. | ||||||||||||||||||||||||
16 | 6 | My favorite resource roundup for design accessibility: https://stephaniewalter.design/blog/accessibility-resources-tools-articles-books-for-designer/ On past projects, I've used a modified version of Stephanie's annotations and they have been wildly successful. Overall, I've had the biggest success with considering A11y as a foundation instead of a phase – it should be integral to each step like including it in requirements, leaving notes on wireframes, creating style tiles, and documenting for hand off. | ||||||||||||||||||||||||
17 | 8 | we are a little scatterd, which is why I am so excited for this session. | ||||||||||||||||||||||||
18 | 1 | Optimize knowledge first in order to motivate is the first crucial step | ||||||||||||||||||||||||
19 | 10 | 1. a11y/inclusive design involvement in component planning 2. document/annotate the implementation details for engineering (e.g. semantic element choices, aria attributes, etc) 3. review common AT UX flows - ensure your team has the tools they need for testing (e.g. JAWS and NVDA, a VM for Mac users) 4. feedback from this testing is given to both design and engineering 5. repeat steps 2 - 4 until ready for release All of these steps are a lot easier if you work with Daniel Henderson-Ede. 😉 | ||||||||||||||||||||||||
20 | 9 | All web developers can join a weekly call to show the Core Ui team how they had implemented a component and ask any questions. There was a11y pros on the call that would run through a test with them to make sure it passed. Most teams were aware that if there apps were not accessible then the company could face lawsuits. | ||||||||||||||||||||||||
21 | 7 | Manual and automated evaluations with different browser and screen reader combinations, visual evaluations, and keyboarding. | ||||||||||||||||||||||||
22 | 6 | We currently run components through an a11y Figma plugin and WebAIM accessibility tools in development. If issues are reported, the designer will make adjustments. I'd like to have a more formal process in place early on in the design phase, prior to development. I'm looking for recommendations of tools/process steps to incorporate. | ||||||||||||||||||||||||
23 | 6 | We start with engineering principles/best practices that we know lead to better accessibility: namely 1) semantic markup and 2) not re-inventing/masking native HTML attributes. There are very very few instances where we force specific attributes. We also implement automated test coverage for common a11y issues. Next, and we are super lucky in this sense, we have a dedicated accessibility team that will user test our components. This is hugely valuable, as the automated tests will often miss painful UX around accessibility features. Finally, we are mindful of where our user's ask for support or clarification on accessibility issues (or when we discover good actionable advice), and we consider how we can add these tidbits of info to the documentation for the design system. The right info at the right moment can be super valuable. | ||||||||||||||||||||||||
24 | 0 | Automated testing and user-run testing. We're still developing our DS, and have not put any code to paper yet so to speak. interested in seeing who is doing what for us to base our system on. | ||||||||||||||||||||||||
25 | 8 | We have internal specialists and a national agency that help us follow the WACG guidelines for our components. During the process our developers implement and test accessibility by each component. | ||||||||||||||||||||||||
26 | 7 | We have an employee who's job is to be up to date and certified in WCAG standards. They are the gurus and are consulted and part of every project. | ||||||||||||||||||||||||
27 | 10 | My current team has a dedicated accessibility team. They have open office hours twice a week and do accessibility interviews. These interviews are with real people who have different disabilities. It's been so incredibly insightful! I recently attended one where they interviewed someone with limited motor function. It was so obvious that the tools designed to assist weren't helping at all. I thought it brought so much clarity to the problem. Looking forward to this weeks discussion! | ||||||||||||||||||||||||
28 | 7 | Hi Ben!! 👋🏻 At Lumen, it starts with the design team making purposeful decisions on color contrast, legibility, and the semantic usage of elements. Once designs are passed off the engineering and eventually QA, there is a list of standards that must be met before a component is released to production. | ||||||||||||||||||||||||
29 | 5 | A11y dept review | ||||||||||||||||||||||||
30 | 7 | The Canadian DS lead has weekly calls with a11y experts (myself and 2 others) to review and discuss ongoing work with an a11y perspective, which is fantastic! We are also included in conversations with the component library engineers. We're still missing a step where we can review/test built components before any new release of the library package, but that's in discussion/planning now. Unfortunately, the Canadian DS is an extension of the Global DS, so it can move faster, but leaves me with the challenge of moving these conversations and adjustments upstream and into a slower pace layer where it can have broader reach. [My purview is a global product offering, so that's something I am still looking to tackle. :) ] | ||||||||||||||||||||||||
31 | 9 | We were recently sued and had an external company audit our entire experience. Our web team spent two quarters updating our entire library to fix all of the accessibility issues that were found (I think over 900 issues were reported). Suffice it to say that our system is pretty accessible now. Still a nine because there is always room for improvement ;) While I wouldn't recommend getting sued as a means of making accessibility a first-class citizen, it sure as hell works. | ||||||||||||||||||||||||
32 | 5 | not a developer, Linkedin led me here tho | ||||||||||||||||||||||||
33 | 7 | Embedding web accessibility as part of the conversation and work across all disciplines, and across all phases of work. From discovery, through to research, to design, development, testing and communications. | ||||||||||||||||||||||||
34 | 8 | Automated testing, trying to do annotations | ||||||||||||||||||||||||
35 | 7 | Manual testing | ||||||||||||||||||||||||
36 | 8 | We plan, design and develop all components to meet ARIA and HTML5 specifications, and adhere to web accessibility best practices - what we haven't done yet is have those components reviewed by users with disabilities - but this is something we're planning for in the coming weeks. | ||||||||||||||||||||||||
37 | 5 | Now, they are reviewed and annotated prior to development. Previously, they were not. | ||||||||||||||||||||||||
38 | 5 | We integrated axe core into our testing framework in only the last few months and have a researcher leading accessibility whose done a manual audit of all of our components to see how WCAG AA they are. From here on out, our components and enhancements are required to pass accessibility checks before we integrate them into our design system | ||||||||||||||||||||||||
39 | 7 | I wish I can give something an accessibility stamp of approval in the docs site | ||||||||||||||||||||||||
40 | 7 | Historically our company has been pretty reactive to vendor audits around compliance. There is some minimal automated testing done with Axe, but there aren't formal requirements beyond addressing violations found during the audit. Since joining the company a few months ago, I've been actively looking at how we can be more proactive about accessibility, both with automation and manual testing, to help prevent regressions. Long-term, I really hope to get our design system to support accessibility beyond compliance by having people with disabilities support usability testing at the component level to help drill into the nuances that can make the experience better. | ||||||||||||||||||||||||
41 | 8 | We use axe-devtools + other deque tools! | ||||||||||||||||||||||||
42 | 3 | Contrast, don’t rely only on color, interactive elements are easy to identify. | ||||||||||||||||||||||||
43 | 8 | As a web developer, I integrate testing with assistive technologies into the process of building digital assets. So, when I'm building a new component, I test with the keyboard, Windows Voice Access, NVDA screen reader and in Windows High Contrast Mode. | ||||||||||||||||||||||||
44 | 5 | Not sure | ||||||||||||||||||||||||
45 | 6 | I wish we defaulted to using the examples from the top library/libraries for functionality and then added accessible styles on top to match our brand | ||||||||||||||||||||||||
46 | 8 | A11y starts with our design and ux teams. We then dev into our system. And we know our individual components are accessible, but I think where it falls apart a bit is implementing into full pages. Where now it has to act as a whole but was designed/dev'd as an individual. | ||||||||||||||||||||||||
47 | 8 | We're fortunate to have an A11y review team w/in our Risk department. 1. We send all designs through an A11y review before building out our Figma libraries or coding 2. Our tech teams put the code through an A11y review and create a TalkBack document for each component. So, while we design w/ best practices in mind, we do get support from our specialists w/in the company. Next year, the same rigor is expected to be applied to our internal tools (it wasn't before!!!). And, feature builds are expected to go through a technical A11y review to catch any of the weird things they do/not handled by the system. | ||||||||||||||||||||||||
48 | 8 | In the very beginning when we were starting work to do a major rebuild to our then component library, we specifically hired an accessibility specialist developer to our team. We others weren't that deep into accessibility and techniques to ensure that, but having that specialist really helped us others to get into it. Obviously you need also motivation and passion yourself too to learn and ask and will to understand, study the criterion etc. But it's really good to have someone who already knows a lot. I think today it is already easier to get started since for example the WAI ARIA patterns library is already pretty mature. And there are more and more good blogs by specialists. For example Adrian Roselli's blog is invaluable. I don't know if I can put it into a process, but you need to understand the criterion and the intent, have empathy, have some identified go-to resources and willingness to google and read and evaluate the options. (And still you can go wrong and you just have to learn from your mistakes.) | ||||||||||||||||||||||||
49 | 9 | As designers our accessibility process is done mostly manually: we have many critiques where designers + tech leads critique others work to get many eyes on it and spot flaws with UX and UI (cognitive load, visual accessibility, and motorized functionality, etc) Tools are used of colour contrast checking (Stark plugin for Figma). In the future we would like to have a step by step checklist for designing accessibly. Our engineers utilized automated processes to review code for accessibility requirements. I'm not completely sure of the details here or what is used to reference this analysis. | ||||||||||||||||||||||||
50 | 6 | I’ve done a WCAG 2.2 audit of our components. Whilst it’s uncovered lots of surface level issues, eg - error messages not programmatically linked to inputs (and/or incorrect methods for disabling them), The problem with the approach is context. Running 1650 manual checks across 50 components was an eye watering task but made me realise that no matter how ‘accessible’ a component was - any misuse or misplacement by a product team could make that component absolutely inaccessible. There’s no point in designing and building a highly accessible button if the product team are going to fill it with ‘click here’ 😭 Context is the enemy of a straight answer. Is there a better way of making components accessible without heavily relying on teams to eat an elephant? (your detailed documentation). | ||||||||||||||||||||||||
51 | 6 | Currently: All components have to pass basic Jest axe a11y tests. Some components (an original set) have been a11y tested, but many were copied from product into the DS after that and have not been tested. I'd wager we pass most major critical a11y items on most of our form components, but where things break down are in the usage in-product, e.g. tabbing through a multi-page form, our our "scan this qr code to activate your physical health screening kit" flow. Future: We are getting an a11y audit soon to revisit major product flows and components. I feel our a11y process (for a bunch of fullstack eng!) needs to basically be a) our components are a11y out of the box, and b) here are the N key things to check and how to do so. We CANNOT rely on regular formal a11y audits. All components MUST have a11y tests. | ||||||||||||||||||||||||
52 | 8 | For new components codified in our desktop system we work closely with our accessibility engineering team to review each component. This means we've designed for color contrast, light and dark mode, high contrast mode and designed annotations for screen readers and keyboard users, and written alt text. We also check multiple fonts since our product allows users to customize that. And we've looked at right to left text. Our engineers run each patch past the accessibility engineering team to double check all of those things as well before shipping. You can see an example here: https://acorn.firefox.com/latest/components/message-bar-V5RTUg0H We are not quite as good on mobile. We design for large text, screen readers, keyboard users, etc but we have more work to do here. We've talked about using tokens to introduce a high contrast mode that is custom to Firefox instead of relying on the OS defaults. We've also talked about getting QA to test more accessibility features and more intentionally designing display settings and text size changes. Just a note, for new things we are developing we're not quite as rigid as for components that are a part of the system. We're working on a documentation video for annotations and handoff documentation to improve some of that, along with introducing an accessibility review for every major new feature. We're also working on stopping any S2 and S1 accessibility bugs from shipping when QA finds them in features in regards to any of the above things. | ||||||||||||||||||||||||
53 | 7 | Including an accessibility consultant in the process. | ||||||||||||||||||||||||
54 | 8 | We hired an accessibility expert to our design systems team who help audit our requirements, design and coded components. She also helps upskill the designers in our design systems team on accessibility best-practices so we can become more self-sufficient | ||||||||||||||||||||||||
55 | 9 | We have an extensive Accessibility Charter and Process for our team which is responsible for designing, developing, testing components for the Design System and also overseeing contributions to the Terra DS from the wider Front End Community. I'm referencing the Design Portion of this charter and process below (I won't be able to fit all 3 sections within the character limit! ) 1/3 Design Accessibility Roles and Responsibilities Regular design reviews of Terra components, Core Templates and page level designs will cover the following accessibility requirements. Global Design Assumptions All designs will be responsive, designed to reflow to a 320px viewport Colour palette is accessible and text and UI components meet both 1.4.3 Min Contrast and 1.4.11 Non-text Contrast WIP: All Terra components referenced in designs will be accessible, or have outstanding issues raised on the Terra backlog. We should aim to complete an accessibility review of all components referenced by a design as part of that design deliverable. Accessibility Design Reviews Regular and early accessibility design reviews will ensure adherence to accessibility best practices and WCAG 2.1 ‘AA’ success criteria. Component designs that go through the correct Terra contribution process can be annotated as above, but additional documentation still needs to be provided per component to cover ‘best practices’ for usage (an example is a single checkbox component that is accessible on it’s own, but when grouped, needs a <fieldset> & <legend>) For existing components, this will be documented as part of the A11y review task. For new components, this documentation requirement can be part of the Terra contribution process. | ||||||||||||||||||||||||
56 | 8 | There is an external-ish team of accessibility experts that test the components. Before the component is shipped, or out of beta, we make sure this teams approves it. Also, consumers (users?) sometimes report problems we might have missed, and we fixed them in close collaboration. | ||||||||||||||||||||||||
57 | 6 | I wish there was a component testing in the context they will be used | ||||||||||||||||||||||||
58 | 7 | Linters, QA testing, and external auditing of our components. Testing, both internally and externally, though, haven’t been formalised so are irregular at best. | ||||||||||||||||||||||||
59 | 6 | - using component libraries like radix-ui, that are WCAG conform. - Reading a lot about a11y and iterate over components. | ||||||||||||||||||||||||
60 | 9 | HTML & Aria compliancy Ensuring the right color and size contrast If interactive, ensuring that all the states are done, especially focus state And finishing with the focus order | ||||||||||||||||||||||||
61 | 3 | Automated test, rules for components. I wish use test whit real users | ||||||||||||||||||||||||
62 | 7 | We have a dedicated team of accessibility coaches and engineers who play a crucial role in our design system. They are involved in multiple stages of our workflow. Over the years, they've conducting roadshows and focusing more on the front end of our projects to educate our workforce about accessibility. However, despite their efforts, individual contributors from both design and engineering teams still lack fundamental knowledge in accessibility. We often encounter simple accessibility issues that should be addressed in the early stages of development. This problem persists on the engineering side as well. It is evident that there is still room for improvement and further growth in this area. | ||||||||||||||||||||||||
63 | 8 | 1. Be familiar with Web Content Accessibility Guidelines (WCAG) 2. Design with accessibility in mind from the beginning 3.Apply accessibility standards to design system components: color contrast, typography, states, etc. 4. Test and validate 5. Documentation and education | ||||||||||||||||||||||||
64 | 7 | At T. Rowe Price, we have internal and external accessibility validation of our design system components before they can be released. Internally we use a mix of automated testing and screen readers. Externally, we engage with an agency to provide expert feedback/reviews on our components as well. We are working to add another step to get real users involved in testing the designs. I marked our DS as a 7 because we are continuing to make fixes and improve our process (is anyone really at a 10). There is also shared responsibility in component accessibility. A design system can make the components accessible to spec but if they are used improperly, the accessibility of the experience will be reduced. Happy to speak on this more - I have a background in design systems, front end development, and accessibility. | ||||||||||||||||||||||||
65 | 8 | Being in the government sector we have to ensure our components meet accessibility guidelines. Our team is well versed in this area and we try our best to make sure components are compliant. We also send our components to a dedicated accessibility team that then review and give feedback. I would love for our team to do more testing with real users with these disability. I believe that additional layer of insight would be beneficial in improving the components and overall experience for users. | ||||||||||||||||||||||||
66 | 9 | I use Storybook to build and test my UI components. - AxeCore API. - Keyboard only. - Screen reader (NVDA). - Windows speech recognition / voice control. - Zoom browser to 400%. Once components are integrated into pages / templates / views, I re-test them in their contexts. | ||||||||||||||||||||||||
67 | 4 | I wish there was a screen reader and a way to tab in figma prototypes | ||||||||||||||||||||||||
68 | 8 | All of our components are evaluated against WCAG guidelines. However, we do still occasionally discover instances where we either misinterpreted the guidelines, the guidelines may have changed slightly since the component was built, or some states or variants were not accessible in some edge-case scenarios. | ||||||||||||||||||||||||
69 | 3 | My design team is currently very, very silo'ed from the engineers who are overseas and we work across so many different platforms (SFCC, AEM, React, etc.) that we can't have one system to rule them all. I work at a huge company and manage a team of 20, so turning the ship is really difficult. | ||||||||||||||||||||||||
70 | 9 | - checking for contrast - adding alt text to images - making sure hierarchy is in place - working with UX writers to make sure copy is as simple and straightforward as possible I wish I was working with more users from various demographics to design (with not for) | ||||||||||||||||||||||||
71 | 7 | Trained the DS team in A11y. Created color token pairs to simplify combinations. Reviewed each component change with A11y staff in design and Eng phases. Included A11y staff in office hours for DS customers. | ||||||||||||||||||||||||
72 | 7 | Our system is not quite at the pilot phase so at the moment we rely on best practices during design, axe-core based tooling and Adobe’s react-aria hooks during development. I hope that the interfaces built with our components get tested and validated by REAL users who rely on AT and that the feedback gets relayed back to the DS team 🤞 | ||||||||||||||||||||||||
73 | 9 | We work with an accessibility lead to review component design and align on design decisions (color, focus state styling, tab order) and also rely on QA resources to test for accessibility of components before release. Design team also has A11y certifications. | ||||||||||||||||||||||||
74 | 5 | On the design team we mostly focus on our color contrast ratios and making sure we are including all need interactive states visually represented. Some things are reviewed in the developed component around screen reader needs like where to include aria labels but Im sure there is a lot more we could/should be doing. There is not much experience or knowledge in this area in our org, beyond that. | ||||||||||||||||||||||||
75 | 6 | In the design phase: to have the person designing the component test it with plugins and tools to see if they meet minimum requirements. In the development phase: to have tests done in the code. | ||||||||||||||||||||||||
76 | 5 | We check for main items like color, tap size and states but we don't do enough rigor on the eng side and for smaller details | ||||||||||||||||||||||||
77 | 3 | Our target users are not completely blind because of the particular job that they do, so my designs don't accommodate blind users. However, many of them are older, and users will typically use the mobile app built with my design system outdoors, which does impact the accessibility in different ways. My focus is to use a highly legible typeface, larger sizes than a typical app, and good contrast at all times. | ||||||||||||||||||||||||
78 | 7 | Local testing with keyboard and readers. Proper planning during the design process. Proper collaboration during the design process. If needed accessibility annoation specs. | ||||||||||||||||||||||||
79 | 6 | We have a big accessibility push this year so we’re going through our 80 components and updating them. We have prioritized navigation components like the header and tabs and footer. We’re working it into our regular design system backlog. A very long time, but we haven’t managed to get any additional funding for design system accessibility | ||||||||||||||||||||||||
80 | ||||||||||||||||||||||||||
81 | ||||||||||||||||||||||||||
82 | ||||||||||||||||||||||||||
83 | ||||||||||||||||||||||||||
84 | ||||||||||||||||||||||||||
85 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||
100 | ||||||||||||||||||||||||||