Podcasts about single page apps

In this episode of the Modern Web Podcast, host Danny Thompson interviews Ryan Carniato, creator of SolidJS, about the evolving relationship between client and server technologies in web development. They explore the history of server-side rendering, single-page applications, and how SolidJS bridges these worlds with innovations like single-flight mutations, which cut down on server-client round trips for better performance. Ryan also shares his vision for the future of reactive systems, focusing on async models and proxy-based stores that enable precise state updates with minimal re-renders. Chapters 0:00 – Introduction and Guest Welcome 1:52 – Challenges of Client and Server Models in Modern Web 4:05 – Importance of Page Load Time and SEO 6:00 – Balancing Client-Server Interactions in Frameworks 9:03 – Exploring React Server Components and Astro Islands 12:00 – Single Page Apps and Data Serialization Challenges 16:02 – Understanding the Cost Triangle of Modern Frameworks 20:02 – The Router Approach in Solid and Its Benefits 27:00 – Framework Opinionation and Flexibility in Ecosystems 35:03 – Vendor Lock-in Trends and React's Evolution 43:04 – Single Flight Mutations: Concept and Benefits 46:05 – Current Work: Reactivity and Signals in Solid 52:00 – Exploring Mutable Reactivity and Performance Gains 57:02 – Wrap-Up and Final Thoughts Follow Ryan Carniato on Social Media Twitter: https://x.com/RyanCarniato Dev.to: https://dev.to/ryansolid Github: https://github.com/ryansolid Sponsored by This Dot: thisdot.co

It's the fourth and final episode of our series exploring Laravel. Brian takes us through the deployment process using Laravel Forge and AWS. Aurooba discusses "modern" WordPress development and how WordPress solutions like SpinupWP compare to tools like Netlify and Forge.A full transcript of the episode is available on the website. Watch the video podcast on YouTube and subscribe to our channel and newsletter to hear about episodes (and more) first!Suggest an episode - https://suggest.viewsource.fm/All the code - https://github.com/viewSourcePodcast/suggest-episodeTailcolor (Tailwind Color Generator) - https://tailcolor.com/Laravel Forge - https://forge.laravel.com/Spinup WP - https://spinupwp.com/Brian's website – https://www.briancoords.comAurooba's website – https://aurooba.com (00:00) - S02E04 - Laravel pt 4 (00:07) - Our Completed Laravel App (02:34) - Tailwind and Colors (04:56) - AlpineJS and Package Bloat (07:57) - Single Page Apps on Laravel (09:43) - Brian's Three Open Terminals (11:52) - Scaffolds and CLIs in WordPress (15:03) - Handling Build Assets in your Deployment (18:36) - Deployment - Forge (and SpinupWP) (24:25) - Connecting AWS to Forge (27:44) - Automated Git Deployments (31:20) - Git vs SFTP in Managed WordPress Hosting (34:33) - Other cool things like queues (37:14) - Final Thoughts

Like the UX of a SPA but developing it is a nightmare

Chris is a Senior Customer Engineer on the Fast Track for Azure team at Microsoft. He has a focus in modern applications built with DevOps, microservices, containers, Single Page Apps, RESTful APIs, and cloud technologies following agile practices. In his free time, Chris is a speaker at numerous meetups, an avid reader and a gamer. You can follow Chris on Social Media https://twitter.com/Chris_L_Ayers https://chrislayers.com/ PLEASE SUBSCRIBE TO THE PODCAST - Spotify: http://isaacl.dev/podcast-spotify - Apple Podcasts: http://isaacl.dev/podcast-apple - Google Podcasts: http://isaacl.dev/podcast-google - RSS: http://isaacl.dev/podcast-rss You can check out more episodes of Coffee and Open Source on https://www.coffeeandopensource.com/​​ Coffee and Open Source is hosted by Isaac Levin (https://twitter.com/isaacrlevin) --- Support this podcast: https://podcasters.spotify.com/pod/show/coffeandopensource/support

ResourcesReact To The Future With Isomorphic Apps.Jamstack.NextJs.NuxtJs.Gatsby.Grindsome. Episode Picks:Alfy: middle earth shadow of war Luay:Score Match

Da wir unseren Nutzer:innen einen einfachen und zugleich sicheren Zugang zu unseren Anwendungen ermöglichen wollen, kommen wir am Thema Identity Management nicht vorbei. Hierbei sollten wir wir auf etablierte Standards wie OAuth 2.0 und Open ID Connect setzen. In dieser Folge schauen wir uns das Thema zunächst grundsätzlich an und diskutieren dann die verschiedenen von den Standards vorgegeben Flows. Auch wer beim Identity Management keine vollständige Eigenentwicklung plant, sondern auf Dienstleister setzt, sollte einen Überblick über die verschiedenen Wege der Authentifizierung und Autorisierung haben. Ihr erreicht uns auf Twitter unter twitter.com/robinmanuelt und twitter.com/maltelantin Links: Okta: https://www.okta.com/ ORY: https://www.ory.sh/ Video OAuth 2.0 and OpenID Connect (in plain English) von Nate Barbettini : https://youtu.be/996OiexHze0 OAuth2 with PKCE for Mobile Apps and Single Page Apps: https://www.ory.sh/oauth2-for-mobile-app-spa-browser/ AppAuth SDK: https://appauth.io/ JWT.io: https://jwt.io/

Sophie and Steven's upcoming workshop at Code BEAM V: Shipping Greenfield Elixir in a Legacy World (https://codesync.global/conferences/code-beam-v-america-2021/training/#145shipping-greenfield-elixir-in-a-legacy-world) Dashbit's Broadway library (https://github.com/dashbitco/broadway) Concurrent Data Processing in Elixir, a new PragProg book by Svilen Gospodinov (https://pragprog.com/titles/sgdpelixir/concurrent-data-processing-in-elixir/) ElixirConf 2015 Keynote: The Pendulum by Bruce Tate (https://www.youtube.com/watch?v=vDyy_qUetT0) José Valim's talk on What Elixir is About (https://www.youtube.com/watch?v=QXcedVc2LQM) Sasa Juric’s Solid Ground talk (https://www.youtube.com/watch?v=pO4_Wlq8JeI) Lars' post on the PETAL stack (https://changelog.com/posts/petal-the-end-to-end-web-stack) Bruce's post on PETAL (https://redrapids.medium.com/petal-liveview-and-lamp-eb5e9f81a804) We want to connect with you! Twitter: @BeamRadio1 Send us your questions via Twitter @BeamRadio1 #ProcessMailbox Keep up to date with our hosts on Twitter @StevenNunez @akoutmos @knewter @lawik @RedRapids @smdebenedetto Sponsored by @GroxioLearning

Follow us on Twitter: https://www.twitter.com/juanlizarazog •• https://www.twitter.com/jaredpotter What's the difference between a plain simple index.html static web app, and the "popular" single-page apps built with Vue, React, and Angular? When should you use one over the other? Jared Potter and Juan Lizarazo explore the difference between a static web app and a SPA web app. Along the way, we talk about each's pros and cons and when to use one over the other. For many types of projects - a simple index.html, style.css, and index.js files are all you need. When highly dynamic content is at play, a Single Page App built with Vue, React, or Angular becomes more effective. Learning this distinction will help you become a better web software engineer and help you land your first tech job! --- Support this podcast: https://anchor.fm/devbootcamplife/support

John: Welcome to Iteration, a podcast about programming, development, and design.John Intro — My name is John and I am a software developer for a home services startup.JP Intro — Hi, I'm JP and I am a software developer at a small analytics startuphttps://macwright.com/2020/05/10/spa-fatigue.htmlTopics / Guiding QuestionsWhat's a SPA?From the articleThe main UI is built & updated in JavaScript using React or something similar.The backend is an API that that application makes requests against.The more techincal one:https://developer.mozilla.org/en-US/docs/Glossary/SPAAn SPA (Single-page application) is a web app implementation that loads only a single web document, and then updates the body content of that single document via JavaScript APIs such as [XMLHttpRequest]() and Fetch when different content is to be shown.This therefore allows users to use websites without loading whole new pages from the server, which can result in performance gains and a more dynamic experience, with some tradeoff disadvantages such as SEO, more effort required to maintain state, implement navigation, and do meaningful performance monitoring.Why do developers choose SPAs? Do end-users care about SPAs?What SPAs have you worked on / maintained?0 —When should you reach for a SPA?That's the right use case: Desktop app to the web.Spotify, Figma, photopea.comBreaks REST might be a good time to considerCommunityWhat's wrong with this SPA's?Increased complexity — Development and deploymentOften times: 2 repositories, 2 languages or frameworks(Rails + Vue)(Node + Angular)(Rails + React)SEO + Speed — Have to do "Server Side Rendering"This reminds me of the light switches for "Smart" light bulbs. You've increased the complexity by a factor of 10 to get the exact same results.Maintainability? Stability?If not a SPA then what? (Is this a different Episode?)What's good about server rendered?How much you get for freeAsync fetchingState managementURL's just workStrong ConventionsStable minimal maintenanceWhat's bad about Server Rendered?Page ReloadCan feel clunkyLess ReactiveMobile App — Now what? SPA lays a stronger groundworkWhat's good about SPA'sBenefits are for the userDeveloper Ego'sData foundationsBreaks CRUDCommunityPushing technology forward is a good thing.What's bad about SPA'sHow much of a pain in the ass it is to Manage URL'sComplexity — Front end + Back endAuthenticationImage UploadMultiple API endpoints for a single pageState is way harder in a SPADebuggingClosing ThoughtsSPA's are great when you are breaking "REST / CRUD"SPA's are great when you need multiple consumers of the same dataThis is highly personal, you gotta go with what you love.WiFiPicksJohn — Distraction Free Phone from the book Make TimeMobile: Uninstall all "Infinity Pools" put "Parental controls" on for the rest. 3.5 hours down to 1 hour screen time. So much time back. Switched out twitter for Kindle.Other tip: Instagram Threads — only the shit you care about with no adsDesktop: https://selfcontrolapp.com/ —JP - https://railsnew.io/

Schon in Folge 20 diskutierten Franziska Dessart, Joy Heron, Lucas Dohmen und Eberhard Wolff über Web-Architekturen. In dieser Folge geht es um die Architektur-Optionen für moderne Web Frontends. Wir geben einen Überblick über die Patterns, die wir uns begegnet sind. Wo implementiert man die Logik, wo liegen die Daten und wie findet die Integration statt: Das sind die wesentlichen Fragen, die wir gemeinsame diskutieren werden. Verschiedene Architektur-Optionen wie server-side Rendering, Single Page Apps werden wir wertungsneutral gegeneinander abwägen.

News and discussion about why the talk of "Frontend vs Backend" is wrong, Single Page Apps, seeing the business value of LiveView, and much more! Show Notes online - https://thinkingelixir.com/podcast-episodes/010-frontend-vs-backend-and-business-value-of-liveview/ The post #010 Frontend vs Backend and Business Value of LiveView appeared first on Thinking Elixir.

News and discussion about why the talk of "Frontend vs Backend" is wrong, Single Page Apps, seeing the business value of LiveView, and much more! Show Notes online - https://thinkingelixir.com/podcast-episodes/010-frontend-vs-backend-and-business-value-of-liveview/

Hi everyone!In this recording you can find:➡ full-stack developers vs specialised devs➡ JavaScript vs Ruby➡ Product Lines➡ Frontend as a client or as a variant➡ Opal Rb*****Find more:➡ Andrzej Krzywda on Twitter: https://twitter.com/andrzejkrzywda➡ Andrzej Krzywda on Instagram: https://www.instagram.com/andrzejkrzywda/

Hi everyone!In this recording you can find:➡ full-stack developers vs specialised devs➡ JavaScript vs Ruby➡ Product Lines➡ Frontend as a client or as a variant➡ Opal Rb*****Find more:➡ Andrzej Krzywda on Twitter: https://twitter.com/andrzejkrzywda➡ Andrzej Krzywda on Instagram: https://www.instagram.com/andrzejkrzywda/

In this episode Matt and Mike discuss the difference between various types of websites including static states, server side rendering, and single page apps. With so many different ways to code up and deliver websites to users, the choice isn't always simple. Performance, infrastructure/hosting type, and of course the learning curve all play a factor in what type of website you'll create for your users. This episode goes over some of the technologies at play with each type. Then later in the weekly Web News segment, we discuss the HTML All The Things website and how the project has evolved over time before coding has even begun. You can find us on... Facebook | Twitter | Instagram RSS | Patreon | Spotify Medium | YouTube | GitHub  Reddit | Discord

What's the latest for Identity Server? While at NDC in Porto, Carl and Richard chatted with Dominick Baier and Brock Allen about their latest work on Identity Server. The conversation goes through the various current generations of attacks on web pages, how Single Page Apps behave differently, and more! Great conversation about the current state of web-based security and how you can do more.Support this podcast at — https://redcircle.com/net-rocks/donations

What's the latest for Identity Server? While at NDC in Porto, Carl and Richard chatted with Dominick Baier and Brock Allen about their latest work on Identity Server. The conversation goes through the various current generations of attacks on web pages, how Single Page Apps behave differently, and more! Great conversation about the current state of web-based security and how you can do more.Support this podcast at — https://redcircle.com/net-rocks/donations

Michael got an Apple Watch. Emily galavanted her way through Denver Startup Week. Kyles's son gets badged up, Bobcat style. All the feels. Our thoughts on the new iPhones, there's three. We get down and dirty with everything Single Page Apps, it's SPA time.

JSJ 271: SharePoint Extensions in JavaScript with Mike Ammerlaan and Vesa Juvonen This episode is a live episode from Microsoft Build where AJ O'Neal and Charles Max Wood interview Mike Ammerlaan and Vesa Juvonent about building extensions for SharePoint with JavaScript. [00:01:28] Mike Ammerlaan introduction Mike has worked at Microsoft for a long time on multiple Microsoft products and projects. He's currently on the Office Ecosystem Marketing Team. [00:01:52] Vesa Juvonen introduction Ves a is Senior Program Manager for the SharePoint Splat team. He's been with Microsoft for about 11 years and manages the community and documentation for the SharePoint framework. [00:02:18] What is the SharePoint Framework? This is how you write SharePoint extensions with JavaScript. SharePoint has changed. It now works with common modern development tools and web development techniques. SharePoint consolodates the extension effort [00:03:32] What is SharePoint? File sharing, team sites, communication points for teams. Part of Office 365. You use Web Parts to add functionality to SharePoint. Web Parts provide functionality like widgets and are scoped to a team, group, or set of users. It's usually hosted on premises, but you can also use it with Office 365 as a hosted solution. [00:05:56] What extensions can you build for SharePoint? You can build widgets for your front page or intranet. You can also add user management or data management or document management. Examples: Dashboards Mini Applications Scheduling and Time Tracking Document Storage Source code repositories [00:07:39] What is WebDAV and how does it relate? WebDAV is a protocol for accessing documents and SharePoint supports it among other protocols for managing documents. [00:08:36] Do I have to build front-end and back-end components to get full functionality? You can build the front-end UI with Angular and other frameworks. And then build a service in Azure on the backend. The backend systems can then access Line of Business systems or other data systems. It really does take multiple skill sets to build extensions for SharePoint. [00:11:10] SharePoint on Mobile There is a mobile web app and the Web Parts work through the mobile application. You can also use any browser to connect to the application. [00:12:08] Building extensions with standard Angular or React component libraries There are standard Yeoman templates. You can also pull in the components through React or Angular just like what Microsoft does. Newer Angular versions are designed for Single Page Apps and SharePoint isn't necessarily set up to work that way. The Web Parts are isolated from each other and Angular requires some workarounds. [00:14:30] Getting around sandboxing Google and Microsoft are talking to each other to see how to work around this when there are multiple sandboxed applications that can't talk to each other in very simple ways. [00:15:39] Application library or naming collisions if my UI uses different versions or clobber page wide settings There are guides for a lot of this. React does a bunch of the isolation work. Addons are iframed in and an API token is given to grant access to the data and APIs. Microsoft also reviews and approves plugins. [00:18:30] How do you get started and make money at this? Look at the SharePoint store. You can build things through websites and pages and offer the plugins through the store. You can request a SharePoint tenant installation from the Microsoft Dev Tools for free. Then you can build into the tenant site. The rest of the tools are available on npm. SharePoint Developer Tools [00:22:13] Automated testing for SharePoint extensions Unit testing is built in for JavaScript. Testing the UI's require you to sign into Office 365. There are people doing it, though. [00:22:54] Building internal-only extensions SharePoint is an enterprise tool, so a lot of enterprises may not want to install extensions from the store. You can definitely build and install private plugins for SharePoint setups. They also have their own backend systems that will require custom development. [00:25:50] Office 365, SharePoint, and OneDrive Office 365 is used by people across many different sized organizations and SharePoint is much more enterprise. Office 365 tools store files and information in SharePoint. What about OneDrive versus Sharepoint? OneDrive is focused for one person. SharePoint is focused around a team. But they have the same APIs and use the same technology stack. [00:29:05] The history and future of SharePoint It started out on premises and has moved to the cloud. The SharePoint team is working to keep it available and useful in the modern cloud based era. [00:30:25] What does the API footprint look like? It spans modifying lists, data objects, attributes, items in a list, put Web Parts on a page, modify the experience, and manage and modify access, users, and documents. SharePoint is a way of building a way of conveying information. SharePoint is layers of data and scopes. [00:35:26] Tutorials and Open Source dev.office.com The Sharepoint framework is not open source yet, but they're working on that. They also need to open source the Yeoman templates. Open source samples are available at github.com/sharepoint. Picks Charles Max Wood BlueTick Zapier ScheduleOnce Moo.com Advice: Take the time to go talk to people. Vesa adds that you should go to a session that's on something completely outside your experience. AJ O'Neal The Circle Spontaneity/Happiness: AJ tells a story about a woman he saw running through sprinklers. Oh the places you'll go by Dr. Seuss: AJ talks about a journal entry he read at a yard sale. Mike Ammerlaan Super hot VR on Oculus Rift Vesa Juvonen Family A big thanks to Microsoft, DotNetRocks, and Build!

JSJ 271: SharePoint Extensions in JavaScript with Mike Ammerlaan and Vesa Juvonen This episode is a live episode from Microsoft Build where AJ O'Neal and Charles Max Wood interview Mike Ammerlaan and Vesa Juvonent about building extensions for SharePoint with JavaScript. [00:01:28] Mike Ammerlaan introduction Mike has worked at Microsoft for a long time on multiple Microsoft products and projects. He's currently on the Office Ecosystem Marketing Team. [00:01:52] Vesa Juvonen introduction Ves a is Senior Program Manager for the SharePoint Splat team. He's been with Microsoft for about 11 years and manages the community and documentation for the SharePoint framework. [00:02:18] What is the SharePoint Framework? This is how you write SharePoint extensions with JavaScript. SharePoint has changed. It now works with common modern development tools and web development techniques. SharePoint consolodates the extension effort [00:03:32] What is SharePoint? File sharing, team sites, communication points for teams. Part of Office 365. You use Web Parts to add functionality to SharePoint. Web Parts provide functionality like widgets and are scoped to a team, group, or set of users. It's usually hosted on premises, but you can also use it with Office 365 as a hosted solution. [00:05:56] What extensions can you build for SharePoint? You can build widgets for your front page or intranet. You can also add user management or data management or document management. Examples: Dashboards Mini Applications Scheduling and Time Tracking Document Storage Source code repositories [00:07:39] What is WebDAV and how does it relate? WebDAV is a protocol for accessing documents and SharePoint supports it among other protocols for managing documents. [00:08:36] Do I have to build front-end and back-end components to get full functionality? You can build the front-end UI with Angular and other frameworks. And then build a service in Azure on the backend. The backend systems can then access Line of Business systems or other data systems. It really does take multiple skill sets to build extensions for SharePoint. [00:11:10] SharePoint on Mobile There is a mobile web app and the Web Parts work through the mobile application. You can also use any browser to connect to the application. [00:12:08] Building extensions with standard Angular or React component libraries There are standard Yeoman templates. You can also pull in the components through React or Angular just like what Microsoft does. Newer Angular versions are designed for Single Page Apps and SharePoint isn't necessarily set up to work that way. The Web Parts are isolated from each other and Angular requires some workarounds. [00:14:30] Getting around sandboxing Google and Microsoft are talking to each other to see how to work around this when there are multiple sandboxed applications that can't talk to each other in very simple ways. [00:15:39] Application library or naming collisions if my UI uses different versions or clobber page wide settings There are guides for a lot of this. React does a bunch of the isolation work. Addons are iframed in and an API token is given to grant access to the data and APIs. Microsoft also reviews and approves plugins. [00:18:30] How do you get started and make money at this? Look at the SharePoint store. You can build things through websites and pages and offer the plugins through the store. You can request a SharePoint tenant installation from the Microsoft Dev Tools for free. Then you can build into the tenant site. The rest of the tools are available on npm. SharePoint Developer Tools [00:22:13] Automated testing for SharePoint extensions Unit testing is built in for JavaScript. Testing the UI's require you to sign into Office 365. There are people doing it, though. [00:22:54] Building internal-only extensions SharePoint is an enterprise tool, so a lot of enterprises may not want to install extensions from the store. You can definitely build and install private plugins for SharePoint setups. They also have their own backend systems that will require custom development. [00:25:50] Office 365, SharePoint, and OneDrive Office 365 is used by people across many different sized organizations and SharePoint is much more enterprise. Office 365 tools store files and information in SharePoint. What about OneDrive versus Sharepoint? OneDrive is focused for one person. SharePoint is focused around a team. But they have the same APIs and use the same technology stack. [00:29:05] The history and future of SharePoint It started out on premises and has moved to the cloud. The SharePoint team is working to keep it available and useful in the modern cloud based era. [00:30:25] What does the API footprint look like? It spans modifying lists, data objects, attributes, items in a list, put Web Parts on a page, modify the experience, and manage and modify access, users, and documents. SharePoint is a way of building a way of conveying information. SharePoint is layers of data and scopes. [00:35:26] Tutorials and Open Source dev.office.com The Sharepoint framework is not open source yet, but they're working on that. They also need to open source the Yeoman templates. Open source samples are available at github.com/sharepoint. Picks Charles Max Wood BlueTick Zapier ScheduleOnce Moo.com Advice: Take the time to go talk to people. Vesa adds that you should go to a session that's on something completely outside your experience. AJ O'Neal The Circle Spontaneity/Happiness: AJ tells a story about a woman he saw running through sprinklers. Oh the places you'll go by Dr. Seuss: AJ talks about a journal entry he read at a yard sale. Mike Ammerlaan Super hot VR on Oculus Rift Vesa Juvonen Family A big thanks to Microsoft, DotNetRocks, and Build!

JSJ 271: SharePoint Extensions in JavaScript with Mike Ammerlaan and Vesa Juvonen This episode is a live episode from Microsoft Build where AJ O'Neal and Charles Max Wood interview Mike Ammerlaan and Vesa Juvonent about building extensions for SharePoint with JavaScript. [00:01:28] Mike Ammerlaan introduction Mike has worked at Microsoft for a long time on multiple Microsoft products and projects. He's currently on the Office Ecosystem Marketing Team. [00:01:52] Vesa Juvonen introduction Ves a is Senior Program Manager for the SharePoint Splat team. He's been with Microsoft for about 11 years and manages the community and documentation for the SharePoint framework. [00:02:18] What is the SharePoint Framework? This is how you write SharePoint extensions with JavaScript. SharePoint has changed. It now works with common modern development tools and web development techniques. SharePoint consolodates the extension effort [00:03:32] What is SharePoint? File sharing, team sites, communication points for teams. Part of Office 365. You use Web Parts to add functionality to SharePoint. Web Parts provide functionality like widgets and are scoped to a team, group, or set of users. It's usually hosted on premises, but you can also use it with Office 365 as a hosted solution. [00:05:56] What extensions can you build for SharePoint? You can build widgets for your front page or intranet. You can also add user management or data management or document management. Examples: Dashboards Mini Applications Scheduling and Time Tracking Document Storage Source code repositories [00:07:39] What is WebDAV and how does it relate? WebDAV is a protocol for accessing documents and SharePoint supports it among other protocols for managing documents. [00:08:36] Do I have to build front-end and back-end components to get full functionality? You can build the front-end UI with Angular and other frameworks. And then build a service in Azure on the backend. The backend systems can then access Line of Business systems or other data systems. It really does take multiple skill sets to build extensions for SharePoint. [00:11:10] SharePoint on Mobile There is a mobile web app and the Web Parts work through the mobile application. You can also use any browser to connect to the application. [00:12:08] Building extensions with standard Angular or React component libraries There are standard Yeoman templates. You can also pull in the components through React or Angular just like what Microsoft does. Newer Angular versions are designed for Single Page Apps and SharePoint isn't necessarily set up to work that way. The Web Parts are isolated from each other and Angular requires some workarounds. [00:14:30] Getting around sandboxing Google and Microsoft are talking to each other to see how to work around this when there are multiple sandboxed applications that can't talk to each other in very simple ways. [00:15:39] Application library or naming collisions if my UI uses different versions or clobber page wide settings There are guides for a lot of this. React does a bunch of the isolation work. Addons are iframed in and an API token is given to grant access to the data and APIs. Microsoft also reviews and approves plugins. [00:18:30] How do you get started and make money at this? Look at the SharePoint store. You can build things through websites and pages and offer the plugins through the store. You can request a SharePoint tenant installation from the Microsoft Dev Tools for free. Then you can build into the tenant site. The rest of the tools are available on npm. SharePoint Developer Tools [00:22:13] Automated testing for SharePoint extensions Unit testing is built in for JavaScript. Testing the UI's require you to sign into Office 365. There are people doing it, though. [00:22:54] Building internal-only extensions SharePoint is an enterprise tool, so a lot of enterprises may not want to install extensions from the store. You can definitely build and install private plugins for SharePoint setups. They also have their own backend systems that will require custom development. [00:25:50] Office 365, SharePoint, and OneDrive Office 365 is used by people across many different sized organizations and SharePoint is much more enterprise. Office 365 tools store files and information in SharePoint. What about OneDrive versus Sharepoint? OneDrive is focused for one person. SharePoint is focused around a team. But they have the same APIs and use the same technology stack. [00:29:05] The history and future of SharePoint It started out on premises and has moved to the cloud. The SharePoint team is working to keep it available and useful in the modern cloud based era. [00:30:25] What does the API footprint look like? It spans modifying lists, data objects, attributes, items in a list, put Web Parts on a page, modify the experience, and manage and modify access, users, and documents. SharePoint is a way of building a way of conveying information. SharePoint is layers of data and scopes. [00:35:26] Tutorials and Open Source dev.office.com The Sharepoint framework is not open source yet, but they're working on that. They also need to open source the Yeoman templates. Open source samples are available at github.com/sharepoint. Picks Charles Max Wood BlueTick Zapier ScheduleOnce Moo.com Advice: Take the time to go talk to people. Vesa adds that you should go to a session that's on something completely outside your experience. AJ O'Neal The Circle Spontaneity/Happiness: AJ tells a story about a woman he saw running through sprinklers. Oh the places you'll go by Dr. Seuss: AJ talks about a journal entry he read at a yard sale. Mike Ammerlaan Super hot VR on Oculus Rift Vesa Juvonen Family A big thanks to Microsoft, DotNetRocks, and Build!

Kris Van Houten: @krivaten | krivaten.com | Q2 Show Notes: 00:55 - Kris' Interest and Passion for Accessibility 06:07 - Using Ember for Accessibility: Pattern Adoption 10:13 - Context Switch Awareness and Managing Focus 12:08 - Asynchrony and Desired Interaction 14:04 - Building a Form Input Component 19:05 - Things That Are Hard to Catch 22:41 - Assistive Browsers? 28:17 - Making Things Accessible From the Start Resources: Building for Accessibility by Nathan Hammond @ Wicked Good Ember 2015 The A11y Project: Web Accessibility Checklist WCAG 2.0 checklists Why Don't Screen Readers Always Read What's on the Screen? Part 1: Punctuation and Typographic Symbols Mozilla Accessibility Kris' Blog Post Series on Accessibility: Part 1: What is accessibility and why should we care? Part 2: A Primer on Accessibility Part 3: Getting Our Apps Ready for Accessibility Part 4: Building an Accessible Icon Component in Ember Part 5: Building an Accessible Input Component in Ember Part 6: Building an Accessible Alert Component in Ember Part 7: Building an Accessible Numbers Component in Ember Part 8: Building an Accessible Currency Component in Ember Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 72. My name is Charles Lowell, a developer here at The Frontside and podcast host-in-training. With me today is Wil. WIL: Hello. CHARLES: Hey, Wil. Today, we're going to be talking about accessibility in single page applications with Kris Van Houten who is a developer at Q2. Hey, Kris. Thank you for coming on the show. Today, we're going to talk about something that I know a lot of people's minds here and probably elsewhere on the internet, it's a topic that's getting a lot more attention, which is a good thing and that's accessibility. We're going to explore the niche of accessibility as it applies to single page applications. Now, you're a frontend developer at Q2, what initially got you interested in and passionate about accessibility in general? KRIS: I honestly feel my path to passion in this area has been a little bit unorthodox in a number of ways. I basically started out in total apathy of this topic and over the last year, it has turned into a genuine interest of mine. About three years ago, I remember listening to an episode of ShopTalk Show with Dave Rupert and Chris Coyier and they kind of went on this large rant about accessibility and why more developers need to be concerned and compassion about it. Dave Rupert was talking about his contributions to the accessibility project and I'm sitting back and thinking to myself and this is back then, obviously, "Why would anyone who is blind want to use anything that I'm working on." I basically balked at the idea and disregarded it entirely. At that time, I was just getting my feet wet with Ember working on an application with a company here in Cincinnati and we had these conversations about, "I notice that we put this action or a clickable event on a div element, should we not be doing that? Is it that not something that we should be doing?" I remember sitting back and having this conversation and saying, "The ads been crawled by SEO and Ember isn't yelling at us for doing it. It still works fine so what the heck? Let's just go with it." Basically, every single app that come into since then has basically adopted that same mindset even before I joined the team so I know it's not just me who is thinking this. A lot of developers that have been exercising the same way of doing their code. CHARLES: Right, it's the path of least resistance. Everybody's got a job to do. Everybody's got features to deliver so that practice can be very easily self-perpetuating, right? KRIS: Exactly and I think a lot of developers just don't understand the semantic difference between a div or a label or a button or a link and how browsers can actually treat these difference HTML attributes or HTML tags differently because of how assistive technology can utilize them for per person's benefit. That's where I was a little over a year ago basically. When I first started at Q2, that first week, I got pulled into a discussion about design patterns which is another passion of mine and somehow, that turned into me joining a group that was to establish to figure out how to tackle the task of making our large app accessible. Basically, we had a company come in, audit our application and we got a big fat F for accessibility so it's something that we said, "We need to start tackling this problem." Being that, I just started at the company that week, I was going to tell them no but internally, I was panicking and saying, "I got to figure out what is this whole accessibility thing is and why it's important." I started looking for books, articles on the topic and trying to basically flood myself with information. Two things that really transformed my way of thinking was actually a talk given by Nathan Hammond at that Wicked Good Ember in 2015, where he shows an example of building an application without accessibility in mind so basically, doing what I was doing before which is we're adding actions to div tags, we're not really caring about semantic HTML, we're just making the feature or the application work. But then what he does, which I think is super powerful is he pulled up a colleague of his who is blind and had him try to use the application. He just goes through and you can see the struggle and he's actually vocalizing and talking about where he's [inaudible] with this application. Long story short, Nathan comes back up and makes a few adjustments. DHTML has [inaudible] up again and it's night and day difference just by changing the markup and by dropping in the Ember A11y add-on which helps with focusing the browser in certain areas of the content. He's able to totally transform how's individuals able to use the app. For me, that was a super powerful to come in and see that and see someone actually struggle with a website that they were trying to use. I think, [inaudible] where I always saw accessibility was it will only affects people who can't see and I think that's the other area where I've really started to have that paradigm shift was when I realized that this isn't just people who can't see. It's for people who have motor difficulties, who can't use a mouse and how to use a keyboard instead. People who have various vision issues, whether that's cataracts, colorblindness, glaucoma, dyslexia, some in these effects, not just DHTML but also affects color contrast, the fonts that we're using that impacts every area of application design and development and that's where I started to realize that that was where the paradigm shift happened in my mind where I started thinking to myself we really need to start talking about this more and getting other developers on board in general on this. CHARLES: It can be intimidating, especially when it feels like on a single page application, your divs have to do more, so to speak in the sense that it feels that your HTML is fatter. It's not just a thin layer but your HTML is actually part of the UI. KRIS: Exactly, yeah. CHARLES: When it comes to having this paradigmatic shift that you're describing, when you're looking at your single page applications, are there any insights into the general structure of the application that you feel like you've gained that are foundational, they kind of transcend accessibility? I guess, what I'm saying is, is there any way that you become like a better developer or been able to recognize foundational patterns because of having these insights surrounding accessibility? KRIS: I've been working with Ember for about three or four years now, basically since it was still in beta. Over the last several years, I have started to accumulate a lot of knowledge as to how we can utilize Ember to do a lot of the heavy lifting for us. When I started getting more passionate about the area of accessibility, first question that came into my mind are how can we use Ember to do some of the heavy lifting for us. For example, some of the things that I had done was go through and start working on developing a couple of components that basically cover a lot of things that I find ourselves doing [inaudible] a lot. Whether that might be a component to just plain icon on a page or a component to display input on a page. What we're able to do is using Ember, we can say, "Here's the icon I want to display but if I don't happen to pass in an aria-label attribute, for example. The component will add the 'aria-hidden=true' for me. Being able to really utilize the power of Ember to do some of that stuff for us on the back side of things, I guess you could say it magically. CHARLES: Let me stop you there for a second and unpack that example. What you're saying is, if I'm going to put an input on the page, if I actually don't assign an ARIA role, it's going to hide it from me? KRIS: No. I was thinking of an icon components, say if I'm using Font Awesome, for example and I want this with the trash icon so I wrote a component for our specific icon library that we're using. We pass in the icon that we want to display, again that could be the trash icon and we can also pass in an aria-label attribute to add a label to that span that will be read to the user. But if we don't pass that attribute in, the component will automatically add the 'aria-hidden=true' attribute for us so basically it skips over it. CHARLES: Yes so it won't be just garbage for a screen reader or someone navigating with a keyboard. WIL: Yeah, otherwise the screen reader tries to read the content of the icon CSS which is just the Unicode. CHARLES: Right. KRIS: Yeah. What we really is trying to figure out and what I've spent a lot of my time, especially in writing my blog series on this was while we are using React or Vue or Angular or Ember or whatever, how can we utilize the power of the single page application frameworks to do some of that heavy lifting for us in the background without us needing to explicitly define everything. I'd say, especially when you work on a large team like what I work on currently, we can't expect everybody to be extremely well-versed in the area of accessibility so if we can do some of the work for them and just encourage them to adopt these components in their daily workflow, it does some of the work for us. That's what we're working on and talking a lot about at Q2 is basically this pattern adoption. CHARLES: Right so it sounds like to kind of paraphrase, whether you're working in any framework most of them have this concept of components so really leaning hard on that idea to make components at the very granular level aware of their own accessibility. Is that fair to say? KRIS: Yeah, obviously there's more I'm sure as we go for the conversation about some of the things that I've tackled in this area but long story short, being able to utilize and recognize, you have this extremely powerful JavaScript framework at your disposal to do some of work for you so why not equip to do just that. CHARLES: Yeah. I guess that falls into my next question, which is there are component level concerns and if there are other component level concerns, I definitely want to hear about them but what immediately leaps to mind is there are also cross-cutting concerns of any single page application, what's the state of your URL and if you're using a router. Some of the content on the page is going to be changing and others isn't like how do you cope with that? What are the cross-cutting concerns of an application that span components and then how do you cope with them? KRIS: I think one thing that comes to mind as you're talking is the whole area of context switch awareness. If I click a link, if I go from the home page of an application to my profile page, how does a screen reader know that that content has now changed to present this new information to the user? I know what we were able to do was we were able to drop in the focusing out with component that's put out by the Ember accessibility team, which basically whenever we render to an outlet, that's utilizing this focusing outlet component, it will focus the browser to that main area and start presenting that information back to the users. One area that was at the top of our list as we start tackling accessibility was we need to figure out this whole context switch awareness thing because -- this is back then obviously when we first got started -- back then there was no way for a user to know when the page changed so they would basically be sitting there, waiting for any kind of feedback or whatsoever to be presented back to them and it just wasn't happening. I would say, managing focus is probably one of the top level concerns when it comes to single page applications because it's a single page application so if you click a link, the page isn't completely refreshing, prompting the screen reader to present the information back to user. That's one of the key areas that I think of. CHARLES: What about things like asynchrony because a lot of times, these context switches are not boom-boom, one-two. The content on which you want to focus isn't available yet. Usually, the analog from a visual UI would be a loading spinner or a progress bar. How do you deal with those to say, "Your content is not quite ready. If you're made to wait it's because we want your content to be of the highest quality." KRIS: Sure, yeah. We were able to drop in the focusing outlet components in our application and it took care of a good chunk of the work but it seems like in our application, we're doing something that might not be as conventional as the rest of the Ember community would like them to be so we might not use the model hook as we should. It's hard for the page to know when the contents actually ready, when it's been rendered to the DOM to present back to the user. One thing that I'm currently trying to tackle right now, to figure out how we can remedy that problem. I probably say, honestly that's the challenge I'm working on right now. I don't have a solid answer to that one at the moment. CHARLES: Irrespective of how it plugs into the tool that you're using, what would just be the desired interaction there, regardless of how you make it work? KRIS: I guess, conceptually what I'd be thinking about is how can we notify the user we're loading content right now and whether that we have an alert box that has the ARIA alerts, basically attributes set on it, that we could pass in new, basically notifications to it to let the user know, "Loading content. Please wait," and then once that content resolves, focus them on that main outlet where the content has been displayed to read that content back to the user. That's how we're trying to think about tackling this issue but we haven't have a time to implement it to see how it's going to work across all the different avenues of application. CHARLES: I did want to come back at the component level. are there any other ways that you can lean on Ember or lean on React or lean on Vue, if you're using a component or in framework, just talk a little bit more about how you use those to unlock your application and make it more accessible. KRIS: One thing I can think of is a way that we can enforce better usage of the framework that we're using is one that comes to mind is a component that I worked out in the blog series that I wrote was building a form input component. Especially, when you're trying to write an accessible app, I think about how can we enforce certain patterns when other developers come in later on and want to add a field to a form or use this component somewhere else in the application. What are some ways that we can enforce that they're doing everything, using the component correctly so that way it renders accessible mark up? What I tinkered around with and we actually just landed in our application is basically a form group component to where we pass in, obviously the value that the input is bound to. But we also pass in a label that is tied to the input and whenever you hit save and the app goes to refresh, if you don't pass the label, there's an assert statement that basically fires up an error into the console and lets you know, "You're trying to use this component, you need to pass into label attribute for the purposes of accessibility and here's the instructions on how to do it." We've been kind of toying around with this idea of enforcing patterns because again, we have several dozen developers at Q2 that are working on this stuff and they're not all wizards when it comes to accessibility but how can we gradually start getting them to the place where they're adopting these patterns and best practices. I'd say, doing things like that, we are enforcing patterns in the usage of the components as well is really a key. One thing that we implement it in our testing framework is the use of a Deque Labs' aXe engine to basically go through, we can pass it a chunk of HTML and it will give us any suggestions that it has to make that content more accessible. We're using that in our test library right now, in our test build and encouraging developers as they write new components, as they go in and modify components to throw new snippets in to make sure that the content that's being spit out here is accessible and then submit your PR again. Just trying to be more hands on in that way. CHARLES: So you actually running a GitHub agent or something that's actually in the same vein as your test suite or if you're taking like snapshotting with Percy for doing visual diff so you're actually running a third check, which is an accessibility check? KRIS: Right now, we were able to land the aXe engine into our test build a couple months back so we're just slowly incrementing that over time. We have a couple challenges in the way of getting Percy implemented but that is in our list of goals to have that running as well. But one thing that I really like about aXe engine in particular is that if your check fails, it refines improvements that you should be making. The nice thing about it is also spits out a link to a page on Deque Labs website. They give an explanation of what have found and basically educates your developers for you. To me, I think that's huge because again, we can't educate every single developer and expect them to be pros at this but we can utilize tooling like the aXe engine or the [inaudible] Chrome extensions or stuff like that to do some education for us. As we work towards automating this further and further by using the aXe engine in our development side of things or using Percy on the test build as well. See, there's all kinds of stuff you can do but that's where we are right now. CHARLES: I really like that idea because in comparison with what we talked about at the top of the show, about how there's this path of least resistance that developers will follow quite naturally and quite rationally, which can lead to not accessible applications. It sounds to me like what you're doing is a establishing the same path of least resistance but having that path guide you towards accessible applications and saying, "This path of least resistance thing, it can be an asset or a liability so we might as well make it an asset." KRIS: Yeah, for sure. We sit down once a week and we talk about whatever challenges we're trying to work through in terms of accessibility. We have a weekly meeting where we sit down and talk about it. I thought one of the key topics to those conversations is how do we get the other developers that are not in these meetings more aware, more informed and more up to speed with this that they care about it, that they're working on it and it's part of their inner dialogue as they're writing out new features that are going to be deployed out to our clients. Lots of challenges there. CHARLES: Yeah. We've talked about some of these problems that you catch, you're actually writing some assertions there on the test build so you'll actually fail if there's certain requirements that aren't met but what are the things that are more intangible? How do those come up in terms of accessibility? What are the things that you can't catch through automated testing? KRIS: Right now, some of things that we're having a hard time testing which Percy will help once we get that implemented is contrast ratios and stuff like that. That's one of the key things that comes to mind for me when I think of the things that are a little hard to catch. I think another thing that's hard to catch, especially at the aXe engine and stuff like that, won't necessarily catch is the flow of your dialogue. When I turn on a screen reader and it starts reading back this page and content to me, sure we can make it so that it doesn't read out the icons character code and a lot of stuff. It presents the information we want back to us but I think, having that information presented back to the user in a way that's legible, that makes sense to them is probably one of the bigger challenges that I've been working on a little bit. One that comes to my mind is like the reading of currencies or numbers. One thing that I found way helpful was Deque put out a very thorough article on how the different screen reader like JAWS, NVDA, Apple's VoiceOver, how they read different types of punctuation, different types of graphics symbols, how they read [inaudible], $123.50, what does a screen reader actually read back to you. That's where I've actually been spending so much of time lately is building on some components that instead of reading back what the streaming will read back by default, which should be, "Dollar sign, one-two-three-five-zero," having actually read back, "One hundred twenty-three dollars and fifty cents," so basically, writing a series of components, I would do some of that, again heavy-lifting force, in that way, our developers don't have to go in and manually add-ons aria-labels obviously. That's been a nice little challenge where something that's we are working on just testing right now and making sure it works right if there is any downsides to doing this but I want a person using a screen reader or other types of assistive technology to hear the information as I'm thinking about it. When I see $123.50, I'm thinking in my head that's, "One hundred twenty-three dollars and fifty cents," not in single digits one right after the other. Those are things that a lot of the automated software isn't catching. It's not catching like, "Your grammar is bad," or, "This isn't making any sense to me." It is catching like are you passing in or applying the attributes to HTML elements that you should be. Are you using semantic structure in your headings and stuff like that?" I think that's one of the areas where developer is need to get their hand dirty, turn on the a screen reader or use any array of different voice-over tools to actually listen to the content being present back to them to see how it's presented. CHARLES: Yeah, it's almost a difference between a syntax error versus a runtime error like we've got a lot tools that can catch the syntax errors and you can put those in and catch where you have something that's malformed but some sentences can be perfectly formed but make no sense and it takes a human set of eyes to make sure if that content is coherent. One of the things that if you're going to ship applications to people, you need to be able to try and measure as closely as possible the environments in which the people will be using your software so you can actually have an accurate measure of whether it works or not. For example, in the Ember world lately in the stuff that we've been doing with acceptance testing in React, we admit people are going to be using a multiplicity of browsers to access this application so it's very typical to use Testem or use Karma to fire up five different browsers, which if you're using BrowserStack, you can do fifty. You know, people are going to be using IE8.1 on Edge or on a Surface. They're going to be using Safari. They're going to be using Chrome and those often surface those issues but I feel like there's no access to the actual screen reader and assistive technologies to be able to make real assertions against those things. I imagine that it would be cool if there was some way that in Testem or in Karma, you could have one of your browsers be like an assistive browser that you could actually assert, I want to assert that it read it as, "One hundred fifty-three dollars and twenty-five cents," and is that on the horizon? Is that even possible? But it seems like something that we have to shoot for if we actually want to measure that these things are working if we actually want to capture data points. KRIS: Yeah, I totally agree. If you look at the documentation on W3 for how these different HTML attributes should be treated by the browser or by the assistive technology, long story short is this is not how -- in several cases -- certain screen readers are presenting the information back to you. It's not how it's treating the content. That's again, one of the areas I thought was way interesting about that. Deque article on punctuation and typographic symbols, which is like we should expect that this software is operating at this level to present this information back to user in such a way where it understands what the dollar symbol in front of a series of numbers means but it just isn't there yet. There's still work to be done. I'm hopeful for the day where our screen readers are a lot more powerful in that capacity. One that makes me a lot more hopeful about that is I don't know if it's just because I've been more interested about this over the last year but it does seem like I'm seeing a lot more people talk about accessibility. I'm seeing Apple putting out videos, talking about the efforts that they're making to make their software more accessible. It does give me hope that there's a lot more visibility on this now. There's a lot more people fighting for this cause to cause these companies to come back and say, "We're going to put more effort into this. We not just going to make a standard screen reader and ship it and just leave it there for five years and no one was going to touch it," but, "We're going to start making improvements." One thing that I did notice just over the last couple months even was that out of nowhere, we use Apple VoiceOver in Chrome, which isn't typically how people use it. They typically use it with Safari. But if you use in Chrome, it will actually read back to you as, "One hundred twenty-three dollars and fifty cents." When I came across that, I was kind of dumbfounded but then I was thinking to myself, the vast majority of people who are using screen readers aren't using this browser but that's really interesting that they're doing this now. I dream of that day where we can basically run a series of mark up through in a test or into a function and basically have to spit back, here's how screen readers going to present this back to you. I'm hopeful for that day. CHARLES: I'm wondering now like why don't major browser vendors, why is this not just a piece of a puzzle that comes when I download Firefox. Firefox has access to my speakers, why isn't there a web standard for how screen readers will treat content? Maybe there's an effort under way. KRIS: I sure hope so. Looking through documentation, we know how things are supposed to work, how we've agreed that they should work and now basically, we're just waiting for the different browser vendors and Microsoft and Apple to make the updates to their streaming technology as well as JAWS and NVDA. I'm hopeful that these changes come soon. These are improvements to the interface. CHARLES: Yeah. Any time there's a gap, you can see that's an opportunity for someone -- KRIS: For sure. CHARLES: -- To write some software that has some real impact. I know certainly, I would love to see some way to roll these things into our automated test suites. KRIS: Yeah. I searched for it but with no avail and it's a little bit beyond my knowledge of how to build something of that caliber. I hope someone else does it because I don't know how. [Laughter] CHARLES: Well, maybe in a year, maybe in two years, maybe in 10, although hopefully a lot sooner than that. KRIS: Yeah. I would judge that at the speed of things were going right now, I'm optimistic that we're going to have some much better solutions within the next year or two on this field. Especially of how much I'm seeing people talk about it now, how much it's becoming a part of the regular conversation of web development, application development. I'm really optimistic that we're going to see some strides in this area over the next couple years. CHARLES: Okay. With the time that we have left, I'm going to ask one more question. Kris, there is something that I wanted to ask you, which is let's say that I am a developer who is working on a team that is maybe it's big, maybe it's small. I've got an application or I'm starting an application and I have a desire to make it accessible. How do I establish that path of least resistance? What advice do you have for someone who's just about to take the first step on that journey to make sure that they have the outcome that they're looking for which is the most accessible single page app that they can have? KRIS: I think it's a great question. I would start out that answer by simply saying to encourage you to be somebody who cares enough to speak up and become an evangelist, become an educator and become an enforcer in your workplace for this work. You don't have to be the most knowledgeable person in the world on the topic. God knows I'm not and I still there were people come to me, asking me, "How do I make this feature, make the guidelines, make it accessible to screen readers," but I'm passionate about this topic and I'm interested in learning as much as I can about those. Step one, just being an evangelists for it. Be interested in it, care about it. I'd say, the next thing is just learn more about semantic HTML. I would say from a lot of the things that I've been trying to tackle with the application that I'm working on, just simply writing semantic markup takes care about 80% of my challenges. In just understanding what are the different elements, what are the different tags are for and how screen readers and other assistive technology see those things. To get started, I would say there's beginner, intermediate and advance stuff. I would say go to the accessibility project, which is just A11yProject.com and read through the content there. It's very entry-level. You can probably read through most of the content within an hour or two and really start to get a grasp as to what level of effort you're looking at in terms of your application. Once you get through that, if you still want to learn more, I'd say go over to Mozilla's developer network -- MDN -- and read through their documentation. On the topic, there is a little bit more exhaustive but it's still really easy to read and really easy to grasp. Based on a content they have shared there, I'd say more of an advance level is actually go through all the documentation on the W3. It's a lot more verbose, it covers a lot more of use cases, it has a lot more suggestions and just stuff ready to go over. I'm still working through that information. There's so much of it but I would say that's as a good place to get started with understanding the different attributes, what they're for and just the importance of writing semantic HTML. I would say some definitely good things to start tinkering with to find some of the low-hanging fruit in your application would be to use some of the assessment tools that are already out there. You have the [inaudible] little JavaScript snippet that you can put in your Chrome favorite's bar or you can use the aXe engine or if you even have an aXe Chrome extension that you could pop up in your application to basically give you report on some of the areas that you should be looking to make some improvements. I think it's important to view accessibility kind of like how a lot of bloggers view SEO, is that there's always more work to be done, there's always improvements you can make but the key is to take those first steps and start making those improvements. One of the nice things about the accessibility project and there's a couple other websites out there that have some of the lists, they basically have a checklist for you to go down. If you're just getting started with accessibility, they have a checklist of all the first things that you should be covering to get your app started in that realm, to start making those improvements. I know you guys do links in the show notes. I can definitely send you those things to those items to get people started. Another thing I find myself doing a lot is while we're talking about something in our chat at work in or just go off in the code pin and mock something out in HTML and then see how the screen reader reads our content back to me and then kind of tinker with it and do a little bit of self-discovery in how this all works together. There's a lot of options out there. I know just threw a lot at your listeners but I'd say, it all starts with being someone who cares about the topic and cares enough to start asking others to care as well. CHARLES: I think that's a fantastic answer and a great note to end on. But before we go, obviously we will include those things in the show notes but also the other thing that we're going to include is a link that you actually, I understand, have a series of blog posts related to all of the things that you've been talking about, which we'll also include. KRIS: Awesome. Thanks. CHARLES: Everybody, go read it. Thank you so much Kris for coming and talking with us about accessibility. I think you're right. It is a topic that's gaining a lot more traction and a lot more mind share in the mainstream that can only be a good thing.

While at NDC, Carl and Richard chat with Cory House about his experiences building Single Page Applications for the automotive industry. Cory talks about the challenges of the industry, including supporting both IE7 and IE8 running on Windows XP and iPad devices. Quite a span of technology there! The conversation digs into UI design, the integration of third party services and meeting the expectations of a customer that is not all that focused on technology. Cory digs into the idea of SPA as a classic desktop application replacement - it can be done!Support this podcast at — https://redcircle.com/net-rocks/donations

While at NDC, Carl and Richard chat with Cory House about his experiences building Single Page Applications for the automotive industry. Cory talks about the challenges of the industry, including supporting both IE7 and IE8 running on Windows XP and iPad devices. Quite a span of technology there! The conversation digs into UI design, the integration of third party services and meeting the expectations of a customer that is not all that focused on technology. Cory digs into the idea of SPA as a classic desktop application replacement - it can be done!Support this podcast at — https://redcircle.com/net-rocks/donations

Eine Podcast-Episode über flexible Client-Architekturen für Desktop, Mobil und Browser – am Beispiel von AngularJS.