 Hello, EmberConf. I'm James Steinbach, and today we're going to be talking about building forms that your mobile users will love. It's easy and unfortunately common to build forms that they won't. Areas where they need to input, where they need to add their email address, but it's getting capitalized. Put in a username, but it's getting auto corrected or spell checked. Type in a number like a one-time authentication code, and they've got an alpha keyboard. These are all correctable problems. But what the point I want to make to start out with is, when we put these hurdles or these pieces of friction through accident, or just being too clever for our own good, sometimes we're guilty of that, I empathize. When we put this friction in a user's path, it seems like a user experience issue, but for many people it is an accessibility issue. And this is the part where Scooby-Doo's gang pulls the white ghost mask off, and we find out that underneath it has been accessibility the whole time. Only it's a good guy and not the bad guy here. This is an accessibility talk pretending to be a UX talk in its title and description. But as we talk about accessibility, I want to remove the idea that some people are able, then some people are disabled, and the world can be kind of divided up in a binary like that. There's a wide spectrum on all sorts of different axes of various kinds of ability. Right now, my ability level is different from what it was three months ago. You can see on screen I'm wearing a neck brace, vertebrae broken in a car accident, as well as broken arm. Right now I'm interacting with the world and devices in a different way than I did before. I go to my phone as my primary device right now because I can hold it in one hand and type everything I need to on it. I don't like my laptop because typing with one hand is cumbersome and I got to go back and forth and it's tiring on my arm. I don't like my tablet because it's heavy. My phone is the easiest thing, but if the mobile experience for me is bad, say on a banking or insurance or hospital website, man, that is frustrating and hard for me to use. And I don't have the privilege I used to have of just saying, oh, I'll bookmark that and grab my laptop next time I'm downstairs. No, when there's friction in the way of a person who's primary and sometimes only device is a mobile device, that's an accessibility issue. We are all at best just temporarily abled. And there are many different issues that affect what we consider our ability levels. It could be the tablet or the device shape or size or portability we're carrying. It could be a condition in Oslo vision relies on screen reader. It could be a physical illness, something like Parkinson's that causes tremors and inaccurate swipe and tap gestures. It could be a perfectly healthy person riding a bus on a bumpy part of town and that gives them the same result as tremors. It could be an injury, maybe something as simple as your kid is interrupting you for the third time today asking for help getting zoom back on for school. But now you've been distracted and your ability has been constrained by something as simple as an interruption. And if you all added your use cases that you've solved for in your careers, we could make the slide three, four times longer easily. And sometimes we worry that when we have a bunch of complex use cases, we need to come up with a bunch of complex solutions. And this one needs a media query and this one needs a different media query and this one needs some JavaScript and this one needs a polyfill library loaded and this one needs a bunch of RE attribute and this one needs... And we get exhausted, we get overwhelmed and the cognitive load is so heavy and I empathize and that's why today I want to suggest a simpler more unified approach for solving lots of varied situations without writing lots and lots of varied workarounds. In fact, as few workarounds as possible. And here's a big takeaway, use semantic markup. I know that sounds like, uh, James, what else am I gonna do? But here we are, it's 2021 and we still have people attaching click events and roll button to a div that should not be happening. Please don't do that. There is a button element that does that for you, okay? Use semantic markup, not just tags, but we're going to learn today three attributes in HTML. They're not part of the ARIA spec, they're just normal HTML attributes and they have semantic, some of them have semantic payoff in terms of how browsers, assistive tech and anything else implement our interfaces. Three awesome benefits here. First, worry less about ARIA. That's right, I said worry less about it. Studies have shown that the more websites use ARIA attributes, the more they miss and overuse them. Unfortunately, the same sites that are really high in ARIA attribute, both everything on are high in accessibility errors. Here's a rule of thumb. A vague UI is better than an incorrect UI. When in doubt, don't just copy paste, don't just cargo call the bunch of stack overflow in. Make sure that the ARIA attributes you're using come from a reputable expert and they really do solve the problem you need to work on. We're only going to look at one ARIA attribute today, in fact, and we're only going to look at it briefly in passing before we get into the heart of the talk. Second benefit is writing less JavaScript. Wait a second, it's a JavaScript framework conference. Why should we write less? Because the less you write, the less you have to test and the easier your workload is. Also, the less you write, the less you send to your users, unless they download, the more power efficient everybody's devices are and the faster your site is for everyone. That's a fantastic benefit. Everyone wins there. And then third, future proof your apps. We're going to look at the way HTML attributes are mapped to accessibility API data points and see how much we get for free today. Future interfaces and devices and software that haven't even been invented yet are going to follow those same standards if they're compliant devices and software. And so we are going to be future proofing our apps by doing ARIA, or not ARIA, sorry, by doing semantics correctly as a baseline. So here's a foundation for how to make an input that will be rendered and handled correctly on any device. You need a label attached to every input. The CodeGolf winner here, the shortest, fewest keystrokes, is wrap your label around the label text and around the input element. This is great. AssistiveTech knows how to announce that correctly to screen readers as associated boom. They're linked. And if you are a desktop user or something that, you know, a user with sighted ability and you tap or click on the label, you'll automatically be focused on the input. Super handy. You didn't have to write a click event for that, developers. The browser did it for free. Sometimes we want to style our label and our input as siblings. And in that case, we separate them like this. We give the input an ID. We give the label a four attribute that matches that ID. And now they're linked in the exact same way, all the same behaviors and accessibility, AssistiveTech, and in browsers. You might not like repeating all the ID stuff. That feels really kind of boring. So you could write a reusable component that has label and input as a pair. And you might be tempted to have to pass the ID in as a prop, but you don't need to. There's an RFC here linked for an Ember helper called unique ID. And every time you instantiate that, you get a unique ID. Let the computer write all those IDs and fours for you. You don't have to worry about human error accidentally duplicating an ID that's invalid HTML. You don't have to worry about making choices and thinking about boring repetitive, okay, I guess I need an ID here. Just let the computer make those boring choices for you. Super awesome. Last scenario, a little bit of a bonus. Sometimes you need a paragraph of text to describe your input, but it's not the label. It's maybe a hint you need ahead of time or perhaps an error message that comes back after a validation event. In that case, give that paragraph an ID and only ARIA attribute I'm telling you today. Put the paragraphs ID into ARIA described by on the input. This is one of the unfortunate areas where HTML doesn't have a way to semantically link that input with a separate paragraph, but the ARIA spec provides this ARIA described by attribute that does do that for screen readers. So that out of the way, let's jump into three HTML attributes. They're plain old boring attributes are not part of the ARIA spec. They don't feel really complicated or hyphenated. And the first one's going to be really familiar to you. In fact, I would be willing to wager that probably high 90s percentage of y'all watching have used this attribute. Type has values like email password or radio checkbox. This semantically identifies the type of value or content the input can hold or accept. And that's semantic information because it has passed along to the accessibility API mapping for various models of assistive tech. And it can suggest more specific labels or other data to screen readers or any other application or device. Here's a screen cap from the AAM specification site. This is the HTML version of the AAM spec. And if we use input type password, we get a whole bunch of things passed right along to four different assistive tech accessibility APIs in various ways. All this information is used by their accessibility models to make it easier for their users to fill out the site. And it's all for free just by using the right type attribute. You shouldn't try to implement passwords. As something other than a password. We try to make them text, but that's a different talk entirely, the whole show password button. Autocomplete is another really useful attribute we're going to practice today. This tells browsers or plugins or software or anything what user data to offer as an autocomplete option. Even better than making it really easy for users to type their answers to our form fields. Let them get away without typing at all. Let them just tap once on an autocomplete option. This also is mapped to a supports autocompletion state and a couple different accessibility API models here. Third and final attribute we're going to focus on today is called input mode, and it suggests the right on-screen keyboard for a device to show to users. This does not have any AAM mappings, so I don't have a screenshot of another one of these tables for you, which means it's just presentational. It's not part of accessibility. Let's practice using these attributes in our last few minutes together now, shall we? A couple of notes before we get into these. I've got Android in the middle and iOS on the end. I've got code blocks that only show you the input. I did not include the label, but you still need the labels, okay? What I said earlier about labels still applies. I just shortened my code blocks for these slides. Here our user needs to add their username. Maybe they're creating it, maybe they're signing back in. There's not a type of value that's semantically appropriate for usernames. We just go ahead and use text, which is the default. But we do add autocomplete username, and that tells password managers with browser plugins or OS integration, as well as the mobile operating system, which might see the user's contact card having a handle saved for the particular domain. Autocomplete options are provided. You might notice here that our keyboard is lower cased. That's not normal. Normally iOS and Android have uppercase keyboards by default. We turned off auto capitalize, auto correct and spell check with the three bonus attributes here. I'm not going to show you those again. Those are just here if you need them on the slide deck. And I want to refer back to them. But if we look at the email option here, the next thing you might want a user to submit, you can see we're still on a lowercase keyboard. We've also got the at symbol available right away with no modifier keys. But the browsers and mobile operating systems have disabled spell check auto complete, or sorry, spell check auto capitalize and auto correct, simply by the fact of this being a type email. All that UI accessibility stuff came for free with a simple using the correct attribute type email. And then that gets us on screen keyboard and then autocomplete email gets us the autocomplete options you see above the iOS keyboard. My Android experience is just an emulator here, unfortunately, and I couldn't set up a contact card. But I did confirm with other Android users that yes indeed autocomplete is a super helpful feature on Android versions as well. Telephone number looks basically the same, not going to spend a ton of time here. But you get the telephone keyboard and autocomplete options by using type tell for the keyboard and autocomplete tell for autocomplete. Addresses are common. Type text is all we need there. There's not a semantic value related to physical location. There are autocomplete options that help us here. Street address is the first one. City, state, zip code, country, are other valid values for autocomplete. And the awesome payoff here is if you mark those inputs all up correctly together, one tap fills in five or six inputs. Very handy. Numbers are tricky. There's type number. And on a desktop computer, this has little up and down arrows at the end of the input itself. It also responds to key presses for the up and down arrows for incrementing or decrementing the number. And on some browsers, you can even scroll over an input type number and that will increment or decrement. That's not what we want most of the time. It is what we want if, say, we're doing like a font size chooser or a scale UI and something like a canva no code design tool on the web. Input type number might be really useful there. But most of the time, the forms we build want users to type in numbers that don't have increment or decrement banked in. Nobody wants to increment their credit card number or their one-time authentication code or their zip code. In that case, we've really actually got an input that's type text that just coincidentally happens to only need digits in the text field. And for that, here's what we don't do. We do not do an unfortunately too common stack overflow option, which says, oh, just use type tell and get the telephone keyboard. No, credit card numbers and zip codes and authentication codes are not telephone numbers. So we never send false information through our HTML to any kind of accessibility software or devices. Instead of use type text, being a little more vague is better than being wrong. And we use input mode equals decimal to get the on-screen keyboard that mobile users are going to want to see. Super handy. Verification codes like a two-factor auth follows the same pattern. Autocomplete is one-time code, is our extra addition to this slide. Dates can be handled as a type date. It's got some UI issues though that are a concern. If you're on iOS or certain versions of touchscreen Windows devices with older edge, you get like three spinning wheels and those are really challenging to spin if you have anything preventing you from being really precise with swiping and tap gestures. Can be really hard to line those up. Android uses a rectangle that kind of covers most of the browser window and it provides calendar-shaped grids of numbers and you kind of have to tap your way through them to get to different months and years, etc. Those tap targets on Android are really, really tiny and also hard to use for people with imprecise tap ability. As well as the fact that if the date you need to get to is more than a few months ago, it's going to take a long time to tap your way through to where you're going. Imagine trying to find your, you know, college graduation date from eight or 12 years ago and having to go month by month to that. It's hard. You really just want to type at that point. And you can do that. We can write an input that's actually three inputs. I like to call this a compound input. And each one of these follows our text decimal pattern. We've got length helpers for our native HTML5 validation and browsers that support it. And to wrap this all up really semantically, a bigger code block. Each of those inputs needs its own label. And then we wrap the whole compound input set in a field set and we give it a legend which acts as a meta label for all three of the sub inputs if you want to call them that. And this is for many users a much quicker way to type and tab their way through the inputs. We're providing a description of what content as well as what format right there in our label. So very semantic and user friendly. And there's more. You've got input mode and type for URLs. There's autocomplete values for anything related to a credit card as well as a birth date. Tons of cool stuff. CSS tip. Sometimes iOS zooms in and out of form fields. What gives? Why is it doing that? It does that if the form field input text area or select is less than 16 pixels calculated font size. Whether it's ms or rems or percents, however you'd wrote the number. If it comes out to less than 16, you'll get a zoom behavior. For a long time, people tried to turn that off with a meta tag. User scale is zero and that's horrible. We should net that disables pinched to zoom entirely which is an accessibility anti pattern. Very bad. Instead, we should make sure that all of our inputs, text areas and selects have a font size of at least 16 pixels. Again, define them in ms or rems or calc with vw and pixels or whatever as long as it calculates down to 16 pixels or higher. Also save your users some cognitive load. A single column layout is much simpler to go down than having to zag back and forth through horizontal scanning as well. So wrapping it all up, we said this talk is really about solving accessibility issues. Making sure more and more users can access what's behind a form on our apps and sites. By solving these accessibility issues at the semantic level, we improved our UIs right now for existing technology and we've future-proofed those interfaces as well for years and devices and users to come. Here are some awesome resources, way more information than I could even fit in this talk. You'll see more examples there. Thanks so much for being a great audience. I would love to continue the conversation if you have follow-up questions. I'm in the Discord now. I'm also at JD Steinbach on Twitter, GitHub and at my blog. Please feel free to contact me and have a great rest of your EmberConf. Take care.