Hi everyone, my name is Anselm and today I'd like to tell you about LocalThirst, a crazy new way to build apps. The traditional technologies are not made for the advanced features that users expect. Local first infrastructure simplifies the app development stack by allowing app-specific parts without a complex stack. Building apps with CRDTs enable real-time multiplayer, cross-device sync, offline support, and auto-merging of conflicts. Public key cryptography simplifies sharing, complex permissions, and enables end-to-end encryption. Local first frameworks like Jazz combine permissions, local first user identity, and cryptography. Managing schema changes in local first apps can be challenging but can be managed with patterns and caution. Backend workers in Local First work the same way as front-end workers, and Jazz allows precise access control for server workers. Jazz enables easy offline-first and local-first user experiences and is used for various apps like Invoice Rater, Learn Anything, and Succulent. Start building local-first apps with Jazz at jazz.tools.

Hey, I'm Sid, and I work on the design systems team at GitHub. Let's talk about building accessible React components with a focus on screen readers. Use the correct HTML element for accessibility. For example, on GitHub, there are three tabs with options. These tabs are made using buttons. Let's see how a visually impaired person using a screen reader would access this website. What do they see? I'm going to enable the screen reader and walk you through what happens. When turning on the screen reader, it sets the context and tells you where you are. For example, on the React app, a button labeled 'Code' has focus and a menu popup. Inside the popup, there are several buttons with different labels. Something interesting happens. If I can't see the UI, I'm hearing buttons but no tabs. Screen readers cannot infer things like tabs from visual design. To provide this information, we can use the ARIA spec and its roles. By adding a role tab list to the div and role tab to each button, the semantics are conveyed. The role overrides HTML semantics. Screen reader identifies tabs, pronounces 'code spaces'. Default behavior of a tab is auto-focus. We can add aria-selected attribute to specify selection. Using React, I'm using an expression to set aria-selected based on the selected tab. The navigation into the tab panel is disorienting. There are separate groups for the tab list and tab panel, and there is a need for navigation between them. Use arrow keys to navigate within the widget. Remove tabs from the tab index, only the selected tab should be focusable. Implement arrow keys for navigation. Press tab to enter the tab panel. Press shift tab to go back up. Keyboard navigation is a common pattern extracted into a hook. Decide which keys to bind based on the widget type. Change selected tab on focus. Consider the ARIA authoring practices guide for keyboard interactions. Differentiate between instant and activated tabs. Follow the ARIA spec and use the APG as an informative resource. Screen readers may not always follow the ARIA authoring practices guide. Use correct HTML elements, add ARIA roles, properties, and states. Implement keyboard navigation. Use a GitHub example of notification settings with proper semantic elements. When selecting notification channels, the options are presented in a pop-up. The focus is on the first checkbox, indicating that it is the first option. The screen reader reads the status of each option. After selecting the desired option, the form can be submitted. The change is saved and the user is notified. The focus is recontextualized on the collapsed menu popup button. Not rendering the fourth option in certain conditions hides it from screen users. Removing the conditional and disabling the fourth checkbox until necessary eliminates this issue. Using IR disabled instead of disabled makes the element accessible for screen reader and keyboard users without affecting styling or click cancellation. You have to add your own class name and make sure it is disabled. It is accessible by keyboards. Voiceover on Mac uses 'dimmed' to signify IR disabled. Adding another span that requires at least one channel. Additional descriptions can be added using aria-describeby. SCREEN READER Only notify for failed workflows. Requires at least one channel to be selected. Dimmed unticked. Tick box. Now you know the label, why it is disabled, and that it's dimmed. And let's see if it's If I mean. Never. Menu popup collapsed. This flow seems more intuitive. You know all your options up ahead. One option was disabled, enabled something else, and it became enabled again. Much more clear. Feels like a better UI. We need to design with accessibility in mind. Accessibility isn't something that you can just sprinkle on in the end. We have to bring it way earlier in the stage. Be careful when disabling elements. Use RLDisabled. Short list of six things to consider. Links on my website. Follow me on Blue Sky.

In this talk, we'll explore what critical CSS is, when to use it or not, how to implement it effectively, and some common challenges and use cases. The critical rendering path is a sequence of steps the browser takes to convert HTML, CSS, and JavaScript into visible content on the screen. Time and CPU are crucial factors in rendering content quickly, especially for mobile devices. Critical CSS matters because the CSOM can't be built incrementally, and the order of CSS rules affects their specificity. There are two primary ways to add CSS to your HTML: inline styles using style tags or external stylesheets using link tags. Critical CSS aligns only the styles needed to render the above-default content, reducing the size of render-blocking styles. There are manual and automatic tools for identifying critical CSS. Critical CSS is commonly used for static websites with statically generated pages. Testing the effect of critical CSS can be done using Lighthouse, Chrome Performance tab, or WebPageTest.org. BISTIs requires some extra handling but offers better performance. Over-inlining CSS and wrong style order can cause issues with critical styles. Implement optimization at build time.

We're going to talk about the age of universal React, the next paradigm shift of React. Universal React is cross-platform and follows the principle of learn once, write once, and run anywhere. React Native is born as a declarative way to build iOS and Android apps. React Native components and APIs are implemented in an interoperable way with React DOM, powering a large part of Twitter's web platform. Code sharing in a universal React app maximizes code reuse, reduces duplication, and allows platform optimization. React Native for Web is the compatibility layer that enables universal development, handling translations between React Native and React Dom. Expo is the framework of choice for React Native, with Expo Router V3 completing the universal story. Challenges in achieving parity with React Native Core due to specific platform implementations. React Strict DOM prioritizes web, bringing web APIs to React Native. Taking a universal React approach can improve performance across platforms. React Native Web and React Strict DOM prioritize performance and accessibility.