Communicating Accessibility in the Design Handoff With Danielle Zarcaro ![rw-book-cover](https://wsrv.nl/?url=https%3A%2F%2Fepisodes.castos.com%2F63d336da70b971-18241126%2Fimages%2FInitial-Accessibility-Craft-Podcast-Cover-3-.png&w=100&h=100) ## Metadata - Author: [[Accessibility Craft]] - Full Title: Communicating Accessibility in the Design Handoff With Danielle Zarcaro - Category: #podcasts - URL: https://share.snipd.com/episode/171ce8eb-4e1e-4d82-b802-9710752cfa3b ## Document Notes ## Highlights - **Provide Accessible Color Matrices** - Provide color combinations with contrast ratios to guide accessible color use in designs. - Avoid including color combos that fail contrast standards to reduce confusion during development. Transcript: Speaker 1 First up is the color combinations. We want to make sure that we're providing what you can and can't use together, right? So this is probably the most common thing. I like Figma. You know, pretty easy for me as a developer to take a look at and use. And so that's what I based my research on for this. It's one of the most common things that I saw. I saw four right off the bat that provided this type of sort of color matrix. So this is typically what I'll get. I've gone into my Chrome and we're in that, you know, Figma community things, resources that Figma makes available to you that you can then just open right up in Figma. Now we're on one that's called Free Accessible Design System, but they don't actually have like the what can go on what color, foreground, background, any of that. This is typically what I'll get as a developer, you know, a list of all the colors, some swatches, and the hex codes and all that. And that's fine. But what's even better is having, for example, this untitled UI one, that's actually its title, it's untitled UI. And so one of the things that they give is, you know, a starting point for creating the color combinations and then also putting in the contrast number and whether that passes double A or triple A. And you can see certain ones in the middle. They don't have any because they don't pass color contrast. I think an improvement to this would be not to include those at all. But in case, you know, somebody wants all the information possible, you know, you have that available to you. And so this way, if somebody does need to pull from, you know, oh, we need this component, and I happen to need some other color or whatever it is. Now you have all the color options available to you. Rather than having to then go generate, the developer has to go and generate their own color matrix. And then everybody is doing the same thing multiple times. And so this just puts it all in one place. Another one that I noticed was wedges. It took me like three times to try to download this. I think there's a problem with the link that they give you, but I did manage to download it. And so they have one available as well. And they have one actually on light mode and dark mode. So you can get a good feel for the colors. And it's just, it's those, you know, if you Google like color matrix there's tools out there where you can input your color palette and it spits out all this information but this one doesn't Have any that don't pass contrast and they give you light and dark mode and then it gives you the you know the amounts that you know maybe we want to stay away from this one because it's too Close or something like that anyway this is i think a really great way to take it a step further when you're doing a handoff to just account for any possible scenario where somebody might Need a color combo. ([Time 0:04:36](https://share.snipd.com/snip/a7af1fed-2d9d-48ba-b388-13362019da6e)) - **Use Scalable Typography Units** - Use relative units like REM and ratios for font sizing and line height instead of fixed pixels. - This approach makes scaling easier and avoids common developer errors in typography implementation. Transcript: Speaker 1 For sizing and spacing, I find that Figma allows you to pretty much use whatever unit that you want. And so some things to make it easier to fit within the standards of not only minimum and maximum font sizes, but also scaling, you know, when would a font size be too small or too big for Any given heading or paragraph or anything like that? These two of the ones that I, I called it United, but it's actually I noticed, what was it called? Untitled. That's actually Untitled UI. I'll have to edit that. So on this slide, it says United UI. That's the untitled UI from before. I guess my brain didn't like that it was untitled. So I gave it a title. So that one and Wedges both had typography options. They both, I think at least Wedges did it in REMS, which is good. There's a lot of info out there about making your font sizes scale, but there's also caveats to a lot of things, especially when you're using clamp and making sure that font sizes don't Get too big or small or overlap. A person that I use a lot for dev-related things is Josh W. Como, I think is how you say his last name. Again, this link is going to be at the URL, kineticiris.com/WPA11y meetup. So he has a link that I think does a really good job of giving you enough technical information if you want it, but not too much that you're overwhelmed. And so he's going to go into some details about, you know, why you might not want to use REMS for padding and, you know, how to go about using max and clamp in a way that's accessible. And so designing in values rather than fixed pixels and using line heights that, you know, get as close to that 1.5 line height that we're sort of striving towards, but just not setting It in fixed pixels. Because if you're giving me, you know, a font size of 18 and then a, you know, line height of 18 pixels and then a line height of, you know, 28 pixels. Well, in order for me to be able to develop that in a way that is most accessible, I don't have to either go to a line height generator or do the math in my head. And that's just so much room for error when, you know, in Figma, you can just hit that setting and just do it in, in that either, you know, on it's the, it's the REMS, but it, you know, you Don't have to include REMS. So it's just 1.5. That's just going to make life easier for everybody. And then just make sure that we have the right ratio, right? So, you know, avoid going to that pixel, you know, default. ([Time 0:09:44](https://share.snipd.com/snip/a4089a21-8e77-4417-a093-9798d242bfe0)) - **Annotate Image and Icon Details** - Add notes for image focus points, direction changes, and opacity to guide accessible image implementation. - Clarify icons' decorative nature and provide alt text or ARIA hidden info early in the design handoff. Transcript: Speaker 1 And so it's hard sometimes to decide who the responsibility falls on for a lot of image accessibility. Making sure that there's enough opacity behind the text for that image, what else can a designer do when it comes to these images to help their developers make informed choices? So first, if we're talking about background images, and I just wrote a blog post on internationalization, and so this was something that I realized I hadn't considered enough. So I have two screenshots here. One is a left to right, you know, version where, you know, English, different languages that you read left to right. And so you have, you know, your white gradient over the image into the transparent so that you can see this person reaching for some stars. And then you have a heading and some subtext. And then next to that one, I have it where I tested, you know, in my I have a browser extension that mimics right to left languages. And the only thing that changed direction was the text. So you have the heading in the text over on the right side, but the gradient didn't follow that. And so now there's some color contrast issues because the text is on top of this sort of blue color. And now I have to worry about if it passes color contrast and all of that stuff, because that gradient didn't flip with it. And this isn't something that you can always necessarily anticipate or that you need to spend time doing. If you're not targeting a language that's right to left, it can be hard to advocate for putting hours into making sure that this works. But it could be something that maybe together over time you start to implement where you're detecting whether these languages exist and what you as a designer want to happen, right? So if I take this image and I mean, if I take this gradient and I flip it with that text, well, then you're still going to have that other side of the image be visible instead of this person Reaching for the stars. The other side of this image is just a blue background with the rest of the stars. And so is that an ideal experience? Or do we need to somehow figure out, you know, a way to flip this image or do something else in order to make this the ideal experience that you're expecting as a designer? So it's just something that I came across that I don't know that I necessarily have a full use case for in terms of a project, but you never know what somebody's first language is. If somebody wants to read this in a right to left language, and that's their browser default, you know, you just don't know. And so it's something to at least consider going forward as something to maybe think about. So this is also relevant to responsiveness. A lot of times, height of a div is fixed, but the background needs to fill the whole space. And so what part of that image do you want to see in the center of that? What part am I focusing on? To guess as a developer, am I fixing the top of the image or the bottom of the image? Am I trying to make it fill it? Or am I scaling it? Like what's happening to this image if the height or the width of that box changes? So that's something that could really benefit someone like me, someone who's a developer. If you just, if it's an image like this, it doesn't have to happen for every image. Speaker 2 This episode of Accessibility Craft is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish. Thousands of businesses, nonprofits, universities, and government agencies around the world trust Accessibility Checker to help their teams find, fix, and prevent accessibility Problems on an ongoing basis. New to accessibility? Equalize Digital Accessibility Checker is here It doesn't have to happen for every image. To teach you every step of the way. Whether you're a content creator or a developer, our detailed documentation guides you through fixing accessibility issues. Never lose track of accessibility again with real-time scans each time you save, powerful reports inside the WordPress dashboard, and a front-end view to help you track down hard-to Issues. Scan unlimited posts and pages with Accessibility Checker free. Upgrade to Accessibility Checker Pro to scan your website in bulk, whether it has 10 pages or 10,000. Download Accessibility Checker today at equalizedigital.com/accessibility dash checker. Use coupon code Accessibility Craft to save 10% on any plans. Speaker 1 Right. So if you have an image where it's a person's face, that's pretty obvious. But is it maybe that maybe it's an image with a person's face, but also a desk and then things behind them? Do we know what part of this image you want visible all the time? So if it's something that maybe you're seeing miscommunications or it's something that you're constantly having to adjust, it's just super easy to add a little comment in Figment And be like, you know, keep this visible as often as possible. So that's just something that I don't think I've seen very much in the handoff that I personally would love to see more of. ([Time 0:13:57](https://share.snipd.com/snip/d087d15a-940c-4acf-baf0-a543a285c0e0)) - **Detail Interactive Element States** - Specify link and button states including hover and focus to reduce ambiguity for developers. - Clarify interaction details for complex components like cards and provide examples of button sizes and spacing. Transcript: Speaker 1 I do have a lot of questions on here on the slide. I'm not going to read them all word for word, but we are going to touch on each of these. So again, if you want to, there's a PDF version on kineticiris.com/WPA11y meetup that could give you these questions word for word, but I am going to hit all of these things. I just know that sometimes it's easier for people to follow along if they are given the things that I'm going to hit. So this is a pretty popular thing with Figma, you know, frameworks and things. The ones that I showed you do have buttons and links as a starting point for you to use and just input your colors, and it'll update it. But one thing I did notice was that a lot of the disabled states that they give you don't pass color contrast. So just make sure that all of the things that you're doing don't include a disabled state if you don't need one. I find it almost never is needed. So that's a situation where don't give too much information if you don't need it. So that's something I wanted to call out about these Figma frameworks, where sometimes they're giving you too much. And so just, you know, get rid of it if you don't need it. So things like Hover and focus. What should a button or link do on hover and on focus? Is it, are we going with the sort of outline? Are we going with a different background? Are we going with something happening on hover? Are we underlining our links and then removing the underline on hover? I strongly dislike having to guess what somebody wants to happen on hover because there are so many options. I've done it so many different ways, and I never know which one somebody wants. And it's just so much easier if you just tell me. And this also applies to things that change state. So a play or pause button. If you're including a video in a design, background video, whatever the video is, it should include that play pause button. And so you're going to, a lot of times I'll get the video with a play button. I'm assuming that if it needs to pause, then that's going to switch and give me a pause icon. Can just give me that in Figma, there's that dropdown that gives you, you know, the different states where it's, you know, you can choose from default and hover, choose from play and Pause, choose from open and closed, default selected for, you know, fancy dropdowns and things. Just if you're including something that does something, what happens after you've done that thing? So thinking through all of those things is going to help make it align closer to that design rather than having me try to figure it out. I do my best. We all always do our best, but it's just going to be better. It's going to come out better if you tell me what you want it to look like. Another really sort of complex-ish element in these designs is cards. And you wouldn't think it's complicated. You have all of the info inside of a box that has an outline on it. But what items are linked? Is it the title? And then you have some categories in there that needs to be linked with, you know, a heart for favoriting features? Are we having to link one thing inside of there? And then when you hover over the whole card, you're going to be able to click? Is it going to have a title and a button linked, which means that I have to then hide the button to screen readers so that they don get two links that are the same thing. There's like all these scenarios for this one little component that's just going to make it easier if you let me know what item is linked and, you know, what's happening in here. Have the whole thing linked. What's happening on hover? What's happening on focus, because I need to make sure that like, if there's an outline, does it, you know, overlap with the item next to it? Or does it go in the right way? Or, you know, all of these sort of scenarios that are just with this one tiny card thing. And again, that's where that focus element comes into play. So if you have images associated with this card, and you know, does the layout change on mobile, and then we sort of have to have a different aspect ratio for that image and all of that stuff. So just as much info as you can give about these interactive elements, that causes the most, not stress, but the most unknowns in these things, because I can make a decision and maybe You don't care. If you don't care about something, honestly, with a component like a card, just say, you know, do what you think. Like put a little note, like, you know, however you implement this is fine. Sometimes, you know, ask your developer that you're going to hand it off to, like, do you care if I don't care? And then sometimes they'll be like, whatever, I'll just do whatever. But if you know what you want, then tell me. And I think, honestly, that if you're going to create a page with some dummy or demo content on there, I would still stay away from using click here or this is, you know, read more. You know, we trying to mimic a real scenario. So include a sentence that says this is a link or something that mimics the real thing just to get out of the habit of by, you know, by doing that, it almost makes it like more likely that Someone might follow that and then use the words click here or something like that. So I would just make sure that like any, you know, demo content you have in there still follows best practices. And then again, with buttons, aside from hover and focus, give an example of a minimum button size and a really long button text. So this is another one that I came across in my internationalization blog post where some languages have like a single symbol for something that we might have three words for. And so being able to know what the minimum button size is is gonna be really helpful when I'm going in and coding it because the requirements are what like 24 pixels the button's not going To look right if it's just a square it's not going to give that same signal of button and so what's that minimum button size that you want and then you know what does the button do if the text Is too long because you can't account for every scenario and so a lot of times I've seen developers put in you know no, no wrap on white space. And so that's just going to make all the text bump out the side because you're trying to get the design right on the hover that shows an icon and does all this stuff. And the way to implement ([Time 0:23:07](https://share.snipd.com/snip/2df53c41-2f3d-4739-897b-674d738aaa86)) - **Clarify Form Accessibility Details** - Clarify form input states, error colors, and autofill types to ensure accessible, standard-compliant form development. - Include notes on user error summaries and avoid overly complex widgets unless necessary. Transcript: Speaker 1 So we have forms next. Again, another Figma thing that I've seen is they do a good job of giving you different states. So you have the regular form field, and then they give you an error state. And like, I need to know what color red do you want as the border I am I putting the default regular red is there a brand red so all of these decisions that like to a designer might seem obvious To a developer I'm like it takes that extra second and then sort of now I have to think in a different gear in my brain and it sort of, you know, messes up a bit of a flow. What are we doing for required? Are we using the nice and simple required text or are we using the asterisk that needs a little bit of more consideration when I'm developing the form? Are we, you know, using any special, which I don't enjoy, special kind of checkboxes or radio buttons or things like that? You know, what in this form do I need to fix or style or anything like that? If at all possible, if you have any kind of interest in making sure that the form is going to follow the expected user behavior. So if you're more of a user experience expert or you have some of that knowledge, it could even be helpful to include the type of field. Some are obvious, like text and email and things. But there's a finite list of autocomplete values that help. It's like autofill values that help a user fill out a form. And so if you're asking for a company name or organization or job title or something like that, it could be helpful to make sure that that gets implemented to put that in with the form that You're filling out. That's a little bit more of a techie thing. You know, I wouldn't necessarily fault you for not including that, but it helps it not get missed. Even if you're just adding a note that says, you know, make sure to look for auto fill values where appropriate. Just a little something to signify that this is a thing that we have to do. Just like you add in a checklist, your launch checklist, you know how to do all these things, but you got to check it off to make sure you do it. So adding a little message there, like make sure to include autofill values, that could be something that's really helpful to signal to the developer to go into that extra setting and Implement that. That's kind of it with forms. The other thing is I like giving users the summary at the top of a form if there's errors after they've submitted it. So is that something that we're including? And if so, you know, make sure you include that at the top of the form, you know, are we giving them that sort of message at the top? So all of these scenarios that you have options for in these forms, it's like you're just helping narrow down all of these possibilities that I can choose from as the developer and giving You what you want out of it. So some anticipated features. If there's the potential for, if it's a company or an organization that might put out a blog post with a complicated table or a graph or some kind of chart or something that's complicated, Is there going to need to be some kind of table description or, you know, image description on these things that I need to make sure that I create a style for and make sure that it works appropriately. It's not always, we try with, you know, base styles to account for all of these scenarios, but sometimes it can be a paragraph tag that is inheriting a font size that isn't right. And it's just a thing that like, not all sites are going to need something like that necessarily, but maybe a user adds an image and then happens to add a caption for, you know, any kind Of reason. There's a number of reasons why you'd add a caption. And so it's just to make sure that like, you're accounting for all of these different scenarios that could happen, given the client, the business you know all of the the possibilities That might happen just it takes literally maybe 15 seconds for me to add it check it and fix it if it's not but it's not something that I might think about if it's not there for me to see in The design. Or it's something that I might not know if it needs to change. Maybe it's totally fine as just a regular paragraph. How much space should be underneath it? I don't know all of these things off the top of my head. And so it might be helpful to give a developer a little bit of extra info on some of that stuff. It's also worth learning, know, in relation to forms, what form fields are accessible and which ones aren't. So if you're showing a client, maybe they have this, you know, form that they need people to fill out, and it's a big part of the redesign. And so you're suggesting a date picker. Is that necessary? Or can we just include a field where they enter a date, right? So there's so many things that can happen with date pickers and date formats and, you know, the accessibility of a given, you know, calendar pop out and all of these things. So if you're giving the client that option without them asking for it, it complicates the development side when it probably would have been just as easy to just add a text field and everybody Would have been happy with that. So just, you know, don't overcomplicate things if they don't need to be. And so learning a little bit about, you know, forms, form fields, different accessible sort of statuses of, you know, what takes an extra JavaScript library to implement versus what's Built into the browser and things like that. And if you're not sure, always, you know, reach out to the developer and be like, hey, I was thinking of suggesting this, you know, is this a good idea? And then I can be like, well, here's some other ways that maybe we can implement that instead. So some additional context is really helpful for, as a developer, if we're doing anything beyond the basics. ([Time 0:31:14](https://share.snipd.com/snip/f09fdbd4-a931-46f6-8774-c7aeed19c5f6)) - **Specify Heading and List Structure** - Provide explicit heading level and list instructions to eliminate developer guesswork. - Indicate visual versus DOM order when it differs to ensure semantic clarity and consistency. Transcript: Speaker 1 In terms of, there are some things as a designer, if you have some, you know, base level accessibility knowledge about like heading levels, for instance. Something like, I think the next slide, I actually do have an example of what I'm talking about. Yeah, so something like this eyebrow pattern that people seem to like to use. When should we use certain tags? A lot of times it's going to be totally obvious. I don't need to know what every heading tag should be, especially because, you know, in Figma, you can name your different font styles. And so if you're using the H2 style and it looks like it should be an H2 on the page, I don't need you to point out every little thing. Sometimes adding too much can kind of be annoying and distracting and, you know, just in the way. But with stuff like this, where maybe it's not so obvious, you know, what are we doing here? Are we, there's a lot of ways that this can go in terms of coding right so you have small text on top of big text are we taking that eyebrow and making that the h1 on the page because this is A hero area so is that the h1 and then underneath that is just a paragraph that looks big are we sacrificing that visual order for a more explanatory DOM order? Or are we sacrificing DOM order for visual order, where maybe in the code, the bigger text is actually the H1 or H2. And so that in the code is on top and the eyebrow text is on the bottom. And then we're switching the order, which I don't always love so this is an you know a less than ideal situation in terms of you know having to mess with the expected experience but it's Not the end of the world and so i just need to know what which is which right so what do you want in this what's what's the expected thing and you know there's always the chance that it could Change based on any given page. But if you're designing page by page, maybe you do know that on this page is going to be this, you know, try to stay as consistent as possible and just give me the information that you know. Again, this is kind of a content thing that I might not feel comfortable making the call for, and I might not know what the better option is. And then something else would be helpful to know is if something should be a list. It's not, sometimes there's like three boxes that are, you know, call outs on a page, right? It's like features that this business does or services they offer. That probably doesn't need to be a list. Maybe it could. I don't know. But like a blog post, I mean, an archive page that has all of the blog posts, maybe should probably be a list. And so if that is something that you feel comfortable making the call on, that's going to get rid of ambiguity and make sure that you're providing the developer with the expected experience. Again, that's a little bit more technical. So you do have to kind of be somewhat comfortable with deciding what should be a list and what shouldn't. Or you think you know, or you have a suggestion for what element something should be, then, you know, definitely let us know as a developer. And then if we're confused, or it doesn't make sense, or it doesn't seem right, then we can always reach out. But if you want to eliminate ambiguity and just make sure that things are done right, if you know something should be in a list, make it a list. If it's something that is, you know, call outs that are horizontal, they just don't, and it's a list, it just doesn't have bullets, it has an icon, make sure that you're telling us that We should be hiding this icon and make it a list. And that should be done in the CSS or whatever it is. So just if there's these patterns that you're seeing or that you're hearing about, that could be done in a more accessible way, make sure that you're letting us know that. ([Time 0:37:47](https://share.snipd.com/snip/5a4e7dd0-6de4-476c-ac44-24fa36c1d7f5)) - **Share Inspiration and Detailed Focus** - Include inspiration examples and clear design intentions for interactive elements to guide accurate development. - Provide detailed notes on focus states from trusted examples to resolve browser inconsistencies. Transcript: Speaker 1 You know, why is this eyebrow up here? I don't know that I care as long as you give me the info, but if you're not sure about a thing, you know, one thing I did want to call out. So for instance, this, this is a good thing about transparency and making sure that I have as much information as I possibly need. I went to the previous slide, we have, you know, this image here that's, that's giving an example of that hero pattern with the eyebrow text, and then the text, you know, that looks like A heading, and then some paragraph text, and there's a background image, and then there's some lines under it. And so this person is telling me those lines that are at the bottom should be separate from the background because maybe they want to be able to update one and not the other or whatever The reason is, that's what they want. And so you're giving the information that I need in order to give you what you're expecting. So rather than assume that I know because they're two separate assets that they need to be coded in there so that you can upload them separately, I might just assume that you had two separate Assets and that you designed it in Figma that way. And then now I need to export the whole thing. Another thing is if, for instance, this background image did need to be exported as one image, do you want me to attach the bottom of the image? Is that important that you see those lines? Or is it important that the image is centered? So that's another example of what I was talking about before about background images. There's all of these scenarios that I'm just guessing at as a developer. And so if you're giving me like, you know, this text might become kind of long. And so we want to make sure that the bluish color that's here in this background image is behind this text rather than the lines. So you telling me what is important out of this image is going to tell me how much padding I need to add on the bottom of this section. All of those things, the more information, the more transparent you can get about some of these things, the better. Providing some inspiration if you happen to find something on the internet that you're using as, you know, your basis for some kind of component or something, just let me know, right? So here's an image example of somebody giving me, you know, focus states, and they're showing me a button on a light background and a dark background. And they've given me not only that there's four pixels between the element and its border, and that the color that it should be on light and dark backgrounds, but they're giving me the Example that they used as, as this. So, you know, if I'm, maybe if I'm, you know, somebody who hasn't done a dotted outline before, and, or if it's supposed to be this very specific dotted outline because sometimes browsers If I'm using you know the built-in css sort of like um you know dotted border it might not render exactly the same and so if you're very particular because this is a brand element well then You can give me that test example and I can take a look at what you're talking about and I can then see what is most important to you in this element. So yeah, if you ever have any kind of inspiration, especially for interactive elements, interactive elements are a big one. Figma makes it really easy to make things fancy and animate, but it's not always the easiest to then recreate and make functional. So if you have any kind of actual inspiration, always include that kind of thing. Our intention is obviously to empower everybody in this process to feel confident in the site at the end of this process. So designers want to make sure that their design is being created in the way that they intended. Developers are trying to make it functional, and everybody wants to make sure that everybody can access it. So providing as much information as possible, making sure that you're covering as many bases as possible, that's going to make everybody, I think, the happiest in this process. This last resource that I have, I actually came across this as I was doing research. And so I found it kind of interesting that her stuff overlapped with my stuff a lot. I think some things might be overkill, like she mentioned, including a focus, like a tab order and everything. And unless that is really important for some reason, I would leave that up to the developer. I think if you had a preference in a two column layout, where you have a sidebar and a main area, and you want the focus should go to the main area first, and then the sidebar second, that's Fine. That's totally fine. But I wouldn't get granular unless it was there was a real big reason for it. But this is an amazing guide. You know, she's she has presented this a couple of times. So I would definitely check that out if you find this stuff helpful. And you want to learn more. It's stephaniewalter.design. And then there's a there's a slash blog slash a designer's guide to documenting accessibility user interactions. It's kind of a long URL. So again, just go to the slides. I have this link there listed. And so that's going to be it for this. Hopefully I didn't go on too long and that we still have some time in case somebody has questions. But yeah, let me know. Behind this text rather than the lines. So you telling me what is important out of this image is going to tell me how much padding I need to add on the bottom of this section. So all of those things, the more information, the more transparent you can get about some of these things, the better. So yeah, providing some inspiration, if you happen to find something on the internet that you're using as, you know, your basis for some kind of component or something, just let me know, Right? So here's an image example of somebody giving me, you know, focus states, and they're showing me a button on a light background and a dark background. And they've given me not only that there's four pixels between the element and its border, and that the color that it should be on light and dark backgrounds, but they're giving me the Example that they used as, as this. So, you know, if I'm maybe if I'm, you know, somebody who hasn't done a dotted outline before, and, or if it's supposed to be this very specific dotted outline, because sometimes browsers, If I'm using, you know, the built in CSS, sort of like, you know, dotted border, it might not render exactly the same. And so if you're very particular, because this is a brand element, well, then you can give me that test example, and I can take a look at what you're talking about. And I can then see what is most important to you in this element. ([Time 0:43:42](https://share.snipd.com/snip/d4dc925f-a061-4b06-af5a-3a680aa8c1f3)) - **Organize Notes for Developer Ease** - Add clear, prominent notes and external examples in Figma to reduce developer confusion. - Avoid clutter in dev mode comments to maintain usability and accessibility of handoff files. Transcript: Speaker 2 Thank you so much, Danielle. That was great. We do have time for questions. So if anyone wants to put them in the Q&A panel, I'd be happy to pass them along. I kind of thought it might be interesting as you were talking about notes and stuff. If you don't mind stopping sharing, I pulled up two things because I always think it's interesting to hear like how different people do it. So I have two Figma files that i that show maybe some evolution and some different ways we've handled dev notes and i'd be curious to get your honest reactions to them so i can share my screen I love that yeah all right all right so um let me think so we started doing more you know i think one of the things that is really hard is trying to figure out where to get notes and for a while We used to have a lot of them on our tasks like we'd have in a base camp project we have a big thing with dev notes each page. They would have huge sections. And maybe in a minute, I can go try and dig one of those up. But then I was like, no, there's some stuff that is just so much easier to say on a file. So what I'm showing right now is the Nurse Pro Plus, like a homepage for their knowledge base. And in this one, we've literally gone through, this is the thing I've learned sometimes, I have to tell developers what heading level to make them. Speaker 1 Yeah, that's what I was saying. It's like, if you want to be sure that it's going to be done right, then yeah, throw it in there. Yeah. Speaker 2 So there's like comments on each one. So like, that's an H1, this is an H2. These just say, this should be an unordered list, because it doesn't have bullet points. And so we're like, let's not assume that a developer will know that this should be a list. It's not even that a developer should know. Speaker 1 It's just there's this like millisecond of stress about should I assume that it needs to be a list or am I supposed to be, do I now have to contact them and tell them that it's going to have To be a list or that it should be a list? And they didn't know that now they don't want it to be. It's just just throw it in there. Throw it in there. Yeah. Speaker 2 Yeah. And then like, like this one down here is an H2, but you notice like it's bigger than those ones. But structurally, it should be an H2. They're just smaller. So they fit better in the design. I don't know. Right? Speaker 1 Yeah. And all that stuff helps me to be able to decide does like what should be, you know, if you don't have like a page that tells me what the main H2 size is, then this way I can be like, okay, cool. So that's gonna be the main H2 size and then I'll have a class for that other one. So it helps me start to strategize on how I'm gonna develop it. Speaker 2 Yeah, so we usually. One of these, although this is not a good example, right? This is what you're saying. You get these things that say, here's all the colors, but it doesn't actually say how they can be used together. Right. So it's not as useful as one of those things. Yeah. Speaker 1 And it's, it's an enhancement, right? So it's not that that's bad in any way. Most of the time, what you're going to give me is going to tell me whether I need a background or foreground color. But I think that just helps give some clarity for everybody. Yeah. Speaker 2 I think something that we've figured out too. So our designer would make this and I'm trying to see if, yes. And occasionally he puts notes out to the side, right? But then structurally he might, it'll happen in a design so we can see like in the knowledge base the h2 is 35 point which i'm always like that's not that's definitely a designer thinking Speaker 1 Not yeah don't give me don't give me points because then sometimes it's a one-to translation into pixels and sometimes it's not and i don't enjoy that yeah but then but then I go through Speaker 2 And I'm like in his head he might have used whatever he thought the h3 or the h4 styles were for this but I'm like nope it's got to be an h2 so I just label it as an h2 but so we were doing but that's Speaker 1 Okay because when you when you click on one of those sometimes you can see that they're using h3 styles which is good because then i can just use an h3 class by looking at whatever the size Speaker 2 Is yeah yeah yeah so so then i noticed sometimes that some of our devs were missing stuff when it was just in comments so i started going through things where i'm like actually pulling Out and putting notes to the side more in addition to the comments So for example, on this student loan planner site, it has this block with tabs. And I'm literally like, accessible tabs with manual activation. Here's the ARIA authoring practice example, because I want it to match that. And I found that that's helpful. I don't know how you feel about that when you get handed, here's a code example. Speaker 1 Do you like that? No, I think it's perfect. And I think if I had any concern about it, then that makes it clear that it's open to like, I don't know, the fact that you've thought about it then means that like, if I had a question about It, or if I'm like, oh, hey, I actually found this one, you know, were you tied to that one this one's closer to the style it just opens up that communication line for me that I think is is Helpful I think the only thing that I would say is sometimes I know it's you have to pay for a different plan in Figma to have dev mode they took it out of like beta and so now they're charging For it it it's helpful if i can dismiss out those comments and then just see the the design because sometimes they get in the way of me clicking on things and so that can be kind of frustrating But i so if there's some kind of figma thing where i can hide a layer or like just do something where i can get rid of them so that i can look at stuff that's that's an ideal scenario as well Or keeping it on design mode and then hiding it on dev mode that would actually be better because I had somebody do it in dev mode and then there's like all these comments and I'm like but I need to click on these things to see the info and I can't because that's in the way so it's like it's I don't know where the best place is to put it maybe next to the text instead of directly On it. I don't, I don't know. Speaker 2 But yeah, this is, yeah, that's why I started pulling more of them out. And then also I couldn't have any of my devs be like, oh, I must've missed that comment. Yeah. Well, it's not collapsed. So, yeah, I mean, I guess you could have missed it if your browser was more narrow, maybe, but, but yeah, so we started to do that like putting some of the comments some of them are kind of Long i'm trying to find one let's like here's one because this is just a weird complex section where you're like how does this even function what does it do right so i had to write a really Speaker 1 Specific thing about like what the client wants here and what is intended and no i think all of that is great because especially with this where it's an interactive thing and is it changing Something underneath and what's happening i don't want to assume i want to assume as little as possible so the more you can give me the more parameters that i have the better i know how To implement it for sure ([Time 0:53:02](https://share.snipd.com/snip/0744aeeb-ce00-4293-9967-a1de5fb0ba47)) - **Consult Deafblind Clients Early** - Ask deafblind clients how they prefer to receive handoff info and editing tools. - Avoid assumptions and customize platforms and workflows to their accessibility needs early in the process. Transcript: Speaker 2 And this is a little bit, I think, beyond design handing to a developer, but handing off to a client and potentially handing that website off to a client or an individual who is deafblind. Do you have any thoughts on that? Speaker 1 It's going to be really important to ask them what they want. I think they're going to have either some kind of program that they favor that works well with the tools that they use or something like that right off the bat, rather than starting and Then kind of being like, oh, you use this, well, I started it in this. Asking right off the bat, you know, what are the platforms or program? Do you use Figma? What's accessible to you? Just sort of finding out from them directly what tools they use. Cause they might kind of be like, you know, Oh yeah. You know, this, my dog is once, once ago, I don't know if you heard her, but she, yeah. So asking them sort of use is going to be really how you, it's going to get you halfway there because if they maybe, I probably, if the developer is the one who needs some kind of accessibility Support in the handoff itself or that maybe they're deaf blind or something like that figma sounds like it would be a nightmare to me trying to figure out all of that crap wade through All of those menus maybe they want something more straightforward maybe they want to be told like in your maybe they'll take all your sticky notes and use that as their as their you know, Stuff. So yeah, I would just ask them how they prefer their information. I don't, it's a very personal thing. I don't have any personal experience because I, you know, I'm not deaf or blind. So I don't, I don't have the answer. I think it's probably its own presentation. Like here's an example of what a handoff to, you know, a blind developer or a deaf-blind developer or somebody who is, you know, reviewing your site or something like that. I think it's always going to be more beneficial to hear from them than me. Mm-hmm. Speaker 2 Yeah, I think, and I'm not 100% certain about the intent of the question if it was asking about the design handoff to a deaf-blind developer or a website handoff to a deafblind person My initial thought on if if you are building a website for a content team that has someone who is blind or deafblind is you probably want to have that conversation pretty early to figure Out what the right platform is. Yes, this person is saying website handoff non-developer. Because my initial gut reaction is if I were going to build a website for a non-developer who is deafblind, I would not use a block editor. And I would not use a page builder.. Speaker 1 I would probably get rid of everything, give them ACF fields and just. Speaker 2 That's exactly what I was thinking. I think I would build a lot of it with ACF fields, maybe ACF flexible content areas, although I'm not 100 percent sure on the accessibility of being able to rearrange those in the editor Because I've never tested that. But I think I'd build more in the old school way that we used to build websites before the block editor existed. Yeah. Speaker 1 And I think that's a conversation you have with them in a discovery session. Like, you know, what are the concerns that you have? You know, I mean, I think it's I think it's obviously a concern, period, that you never know if somebody who is deafblind is going to need to go onto a site and edit it. But, you know, if it's an immediate concern that, you know, that's definitely a conversation to have with them for sure. Yeah. So I think, I think ultimately, you know, I, I can't give a satisfactory enough answer for my liking because I don't, I don't know, but I'd love to know. ([Time 1:00:19](https://share.snipd.com/snip/016a0f4e-3a37-40c3-96b3-7a90149b1361)) - **Support WordPress Users with Docs** - Provide thorough WordPress editing documentation tailored to users' comfort levels. - Customize block editor experience by enabling personalization options like no distraction mode to aid usability. Transcript: Speaker 2 Yeah, I think I would definitely talk to them and find out what they're used to. I have seen a few people who I think actually there was someone who presented at WordPress Accessibility Day last year who was blind and said that she liked the block editor better. But I've also heard from users that they find it very difficult. Speaker 1 I think that's really what you would need to for like the content blog side of things versus the site building side of things like it could be two different scenarios yeah i mean one thing Speaker 2 That i love about the just writing in the block editor is that it supports markdown so you can type headings really easily and links and adding images even and a lot of stuff you can do just With a keyboard without having to use your mouse. But building more complex layouts is definitely more challenging. I would think you'd want to make sure that you have really solid documentation. But that's something that I think all of us as web developers can get better about for any of our customers because many of our customers whether they have disabilities or not I think We over assume their level of comfort with WordPress a lot of times and we're like oh this will be easy for them to edit but but they're not going to intuitively know unless you have a very Savvy experienced WordPress user. And so I would always recommend including in your scope, time to write documentation on here's how you edit this. Here's how you change things. Here's what you should do moving forward. ([Time 1:04:10](https://share.snipd.com/snip/b17194d1-2ae6-433a-bf5c-a0e5cd15e5dd))