Patrick H. Lauke: Keyboard accessibility - basic steps towards a more usable and accessible site / Future of Web Design Touch / Glasgow / 14 September 2009
This document discusses touch events for responsive web design. It begins by explaining how browsers emulate mouse events on touch devices, which can cause problems like delayed responses. Native touch events are introduced as a better solution, covering events like touchstart, touchmove, and touchend. The document explores issues like touch versus mouse/keyboard, multi-touch support, and touch event support across browsers. It provides examples of how to track finger movement and implement swipe gestures using touch events.
This document discusses developing web applications for TV. Key challenges include large screen sizes, imprecise input like remote controls, and variable performance. Design recommendations include making interfaces responsive, optimizing for navigation with a directional pad, and minimizing features like scrolling that don't work well on TVs. Testing and debugging tools from TV manufacturers can help develop and ensure good performance.
This document summarizes new multimedia capabilities in HTML5, including native support for video and audio playback without plugins. It describes how the <video> and <audio> tags can be used to embed video and audio into web pages directly in the browser. It also discusses the various video and audio formats that are supported, such as MP4, WebM, and Ogg formats. The document notes that HTML5 does not specify exact formats or controls, but provides JavaScript APIs to control playback programatically.
This document compares native applications, web applications, and widgets for mobile devices. Native applications have direct access to device features but must be developed for each platform. Web applications can be written once and deployed anywhere but run inside the browser without direct device access. Widgets combine the cross-platform capabilities of web applications with the ability to access device features and run standalone like native applications.
This document provides an overview of various HTML5 APIs for multimedia, including native <video> and <audio> elements, the <canvas> element for scriptable graphics, and geolocation APIs. It discusses key considerations around supporting different media formats in <video> and <audio> and controlling media playback via JavaScript. The document also briefly introduces other HTML5 APIs for offline applications, local storage, and databases. It emphasizes the importance of feature detection over browser sniffing for progressive enhancement.
Extended version of my "Making your site mobile-friendly" talk, including a short look at native applications vs web apps, for the UKOLN DevCSI event "Developing for Mobile Applications in Education" in Reading http://www.ukoln.ac.uk/events/devcsi/mobile_applications/
The document discusses touch and pointer events on websites. It explains that browsers emulate mouse events on touch devices but this causes issues like delayed response. Native touch events were introduced to address these issues. The document then provides tips on how to optimize websites for both mouse and touch using techniques like touchstart/touchend event handling and preventing default actions.
Part II of the standards-next.org workshop on HTML5 with Bruce Lawson, concentrating on audio, video and canvas (plus hints of additional HTML5 API niceness)
This document discusses touch events and how browsers emulate mouse events on touch devices. It notes that mouse event emulation has limitations like delayed dispatching and lack of touch-specific interfaces. True touch events like touchstart and touchmove are introduced to address these issues. The document also covers more advanced topics like multitouch support, gestures, and differences between touch event implementations on various browsers and platforms.
Short presentation focussing on HTML5 canvas - how it works, why it matters. Delivered as part of an Opera-internal set of presentations by the Developer Relations team on 23 February 2010 in Oslo
This document summarizes techniques for making websites work well on both desktop and touch devices. It discusses using touch events, dealing with delays in mouse event emulation, avoiding hover interfaces that don't work on touch, and handling both mouse and touch movement by doubling up event listeners. Key points covered include feature detecting touch support, preventing default scrolling behavior, and libraries that improve touch responsiveness like FastClick.
Keyboard accessibility is important for users with disabilities and should be tested without special software. Websites should have a logical tab order for focusable elements and maintain styles on focus to indicate where the user is. JavaScript behaviors should also trigger on focus and blur, not just hover, and focus should not be suppressed to ensure usability. Complex solutions require managing focus carefully to avoid usability and accessibility issues.
Keyboard accessibility involves several key principles: 1) Ensure all elements can be accessed by tabbing through them in source order without requiring tabindex attributes. 2) Style focus states similarly to hover states and don't fully suppress the outline on focus for accessibility. 3) Attach JavaScript behaviors like hover states to focus and blur events as well as mouse events, since mobile browsers don't fully support hover. 4) Only attach behaviors to focusable elements, not all elements, to avoid unintended accessibility issues.
A talk on front-end developer tools including Yeoman, Grunt.js, Require.js, Bower, and SASS given at Drupal Camp LA 2013. This talk doesn't address Drupal specifically, but it was aimed to give the audience of drupal developers a look into the state of the art.
The document discusses various shell and command line tools to improve productivity for developers, including: - Bash basics like keyboard navigation, piping, I/O redirection - Tools like GNU Screen for multitasking and Vim for text editing - Phing for project automation and deployment - Benchmarking tools like Apache Bench and Siege It provides examples of using these tools and resources for further learning shell scripting and command line skills. The overall agenda is around becoming a more efficient "Bash Ninja" through mastering the shell environment.
This document provides an overview of using jQuery with SharePoint. It discusses how jQuery can be used to resolve common SharePoint issues, improve usability, and quickly build interactive applications without deploying custom code. It covers jQuery basics, common myths, deployment options, maintenance best practices, debugging techniques, and examples of using the SPServices library to interface with SharePoint APIs. The document emphasizes that jQuery is not a silver bullet but can be a useful tool when properly understood and applied.
Modernizr is a small JavaScript library that detects whether browsers support HTML5 and CSS3 features. It allows developers to write progressive enhancement code that provides a baseline experience for all browsers while enhancing functionality for modern browsers. Modernizr tests over 20 features and adds corresponding classes to the HTML element. This allows developers to target styles and scripts based on a browser's capabilities. It is a useful tool for building websites that work across a wide range of browsers without needing to sniff browser versions.
Presentation at ScalaMatsuri 2014 http://scalamatsuri.org/en/program/index.html#session-b-4 http://live.nicovideo.jp/watch/lv191315534#5:12:20
Kazuhiro Sera introduced several of his Scala projects including ScalikeJDBC, Skinny Framework, and AWScala. He discussed some of his philosophies for solid and sustainable development in Scala including using simplified class-based OOP with immutable data structures, avoiding overkill abstraction, writing tests without question, keeping infrastructure lightweight, and ensuring projects have no surprises for newcomers. He welcomed questions during the upcoming AMA session.
Video at http://www.youtube.com/watch?v=HaJnhYPLvx0 Large Drupal projects will generally have a themer or five working alongside the developers, site builders and designers. Themers are the magicians who transform what Drupal wants to do into what the designer wants it to do. Smaller projects also usually need someone on the team who can make sense of Drupal's output, knows more CSS and JS than anyone else and can configure Views with their eyes closed. The thing is — and whisper this, if possible redundancy concerns you — we can bypass the themer entirely. With some simple configuration, a site builder can get Drupal to output exactly the semantic, lightweight markup that any modern front-end designer would be proud of. The designer can be left alone to write the most appropriate HTML, CSS and JS, while the site builder need only choose a couple of options when putting together content types, views and panels to make Drupal behave. A friendly developer may have to lend a hand every now and then, but that’s it. You can get rid of the themer altogether. http://2013.drupalcamplondon.co.uk/session/death-themer
This document discusses progressive prototyping as a design process. It emphasizes that prototyping allows designers to fail in a low-cost environment and iterate on their designs through testing. Different levels of prototyping fidelity are presented, from simple sketches to higher-fidelity visual prototypes. The document recommends starting with simple sketches and adding more details in subsequent rounds of graybox prototyping. It also provides examples of HTML5 and CSS3 techniques that can be used to create interactive prototypes, including new HTML5 input types, CSS3 selectors, and properties for styling buttons. Overall, the document promotes prototyping as a better way to validate designs through an iterative process of testing and refining ideas.
A high level overview of Twig and its functions that was presented at the OC Drupal meetup in February 2014 at KWALL. As Twig is now part of Drupal 8 core, it is still being developed so slides are mostly on Twig itself. Discussion was over what Twig provides to themers. http://www.meetup.com/oc-php http://www.meetup.com/ocdrupal/
This document discusses bringing designs created in Photoshop or other design programs to life as WordPress themes. It covers considerations when slicing designs, using starter themes, building child themes, and inserting CSS. Tips are provided on focusing on high impact elements first, understanding the parent theme structure, and using tools like Firebug to debug designs. Resources for learning more about web development and WordPress theme building are also listed.
Technical details about working with Web CMS systems from a Designer's perspective as presented by Chris Charlton at SxSW Interactive 2010.
Patrick H. Lauke: Keyboard accessibility - just because I don't use a mouse doesn't mean I'm second class / Skillswap Bristol / 11 Nobember 2008
Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/170xwtC. Kevin Moore explains doing client-side data-binding, visual templates, and custom HTML elements in modern browsers with Dart, while providing forward compatibility with emerging web standards. Filmed at qconnewyork.com. Kevin Moore is a consultant specializing in open source web technologies. His experience includes UI platforms in .NET, web applications in Rails, and cutting edge games in Javascript. Kevin is committer and Google Developer Expert for Dart. His projects have highlighted the potential for building rich experiences with Dart.
Slides from my presentation at the London Flash Designer and Developers Meetup, 22 April 2010 for more details see tomaterial.blogspot.com
1. The document discusses using CSS to create visual elements like shapes, logos, and icons instead of images for performance, maintainability, and resolution independence reasons. 2. It provides examples of how to create basic shapes like rectangles, circles, and triangles using CSS properties like border-radius, gradients, and positioning. 3. The document also covers techniques for generating HTML elements, using pseudo-elements, and manipulating elements with transforms to create effects like masks and shadows.
Driven by technologies such as HTML5, JavaScript, and jQuery, innovative new user experiences are thriving on the Web. This workshop, presented by Justin Obara and Colin Clark from the Fluid community (http://fluidproject.org), will provide Web designers and developers with an overview of modern Web accessibility techniques, providing hands-on ways to make HTML5 and jQuery-based applications more accessible, flexible, and inclusive of a diverse range of users. We’ll also cover some of the features of Fluid Infusion, an application framework built on top of jQuery.
Consider this: you’ve worked in web development for a while and you aren’t a novice developer anymore. You can dive into CSS and HTML, with the best of them, and you even know a little javascript. But now you are being told to “consider the user” in your development process and to “make your sites more accessible”. You find yourself asking, “what does all of this mean and how do I do that?” Have no fear. This workshop will expand your knowledge of the web development process by providing you with a few essential tools and tricks needed to help you create more user-friendly and accessible websites. The topics include: - How to incorporate accessibility and usability from the beginning of development - How to make your javascript components more accessible - How to run a simple user testing session that will give you the feedback you need - How to create a faster workflow for CSS and HTML creation from a design
What an expert and deep-rooted C# developer discover about Ruby. Here are the impressions, the oddities and the WOWs.
WCAG is supposed to give us a reasonably objective way of saying whether or not the sites we are building/auditing are "accessible" (to a particular baseline). However, they are only as useful as our understanding and interpretation of the guidelines' normative text. And, of course, it is not perfect - with some omissions, handwaving, and straight-up loopholes. So where does this leave developers and auditors? In this talk - a reprise of a previous talk, now updated to cover new SCs from WCAG 2.2 - Patrick may not have all the answers, but he'll have a good rant around the subject anyway...
Update about Pointer Events Level 3 work for the upcoming W3C Technical Plenary and Advisory Committee (TPAC) 2023 in Seville https://www.youtube.com/watch?v=r0spZl1qaa0 https://w3c.github.io/pointerevents/ https://www.w3.org/TR/pointerevents/ https://www.w3.org/2023/09/TPAC/ https://patrickhlauke.github.io/touch/w3c_tpac2023_pewg/ Cross-posted from https://www.w3.org/2023/09/TPAC/group-updates.html#pointer-events
WCAG is supposed to give us a reasonably objective way of saying whether or not the sites we are building/auditing are "accessible" (to a particular baseline). However, they are only as useful as our understanding and interpretation of the actual guidelines' normative text. And of course they're not perfect - with some omissions, handwaving, and straight up loopholes. So where does this leave developers and auditors? In this talk, Patrick may not have all the answers, but he'll have a good rant around the subject anyway...
WCAG is supposed to give us a reasonably objective way of saying whether or not the sites we are building/auditing are "accessible" (to a particular baseline). However, they are only as useful as our understanding and interpretation of the actual guidelines' normative text. And of course they're not perfect - with some omissions, handwaving, and straight up loopholes. So where does this leave developers and auditors? In this talk, Patrick may not have all the answers, but he'll have a good rant around the subject anyway...
HTML offers many features and attributes that can make your sites more accessible...but only if they're used wisely. Can there really be "too much accessibility"? Audio recording: https://archive.org/details/Psf8August2007.PatrickH.Lauke-TooMuchAccessibilityGoodIntentions
Patrick H. Lauke: Styling Your Web Pages with Cascading Style Sheets / EDU course / University of Salford / 13 February 2006
Patrick H. Lauke: Evaluating web sites for accessibility with Firefox / Manchester Digital Accessibility Working Group (MDAWG) / 1 March 2006
Patrick H. Lauke: Managing and educating content editors - experiences and ideas from the trenches / Public Sector Forums / 10 May 2007
Patrick H. Lauke - Implementing Web Standards across the institution: trials and tribulations of a redesign / Institutional Web Management Workshop IWMW / Birmingham / 28 July 2004
Patrick H. Lauke: Geolinking content - experiments in connecting virtual and physical places / Institutional Web Management Workshop IWMW / York / 16 July 2007
WCAG 2.0 is the new set of web accessibility guidelines that was released in 2008 as a recommendation by the W3C. It addresses some issues with the previous WCAG 1.0 guidelines by being technology-agnostic, having clearly testable success criteria focused on user outcomes rather than techniques, and removing outdated requirements. WCAG 2.0 provides more freedom for authors while still ensuring accessibility. It includes 4 principles, 12 guidelines and 61 success criteria to evaluate websites. The transition from WCAG 1.0 involves evaluating sites based on the new success criteria and testing areas that may be different.
This document provides an introduction to web accessibility. It begins by addressing some common misconceptions about accessibility, noting that it aims to accommodate people with a wide range of disabilities, not just visual impairments. The document emphasizes that accessibility is important for both ethical and legal reasons, and that inclusive design benefits all users. It then outlines key web accessibility guidelines from the W3C, providing examples of how to make content more accessible through proper semantic markup and alternative text. The conclusion stresses that accessibility is an essential consideration for web development.
Patrick H. Lauke: Doing it in style - creating beautiful sites, the web standards way / WebDD / Reading / 3 February 2007
The document discusses common misconceptions and pitfalls around using web standards. It argues that web standards are about more than just validation - they are about semantics, separation of concerns, and pragmatism. Some key points include: using the most appropriate HTML elements to convey meaning rather than appearance; applying styles through CSS instead of presentational markup; avoiding non-semantic class names; and recognizing that not all uses of tables or images are invalid. The document advocates for balancing standards with practical concerns like multiple authors and one-off content needs.
Ian Lloyd/Patrick H. Lauke: Accessified - practical accessibility fixes any web developer can use / South By Southwest SXSW / Austin, Texas, 11 March 2007
One from the archives...presentation about the development of the University of Salford website in 2007
Vanilla HTML is limiting and boring. Our clients demand highly engaging and interactive web experiences. And wouldn’t you know, with just a bit of HTML and JavaScript we can craft amazing custom controls, widgets and effects that go far beyond the confines of traditional static markup. But how can we ensure that these custom experiences are both understandable and usable for people with disabilities, and in particular those using assistive technologies such as screen readers? In this talk, we will look at the basics of making some common custom-built components accessible - covering how browsers and assistive technologies interact, the limitations of HTML, and how ARIA can help make interactive experiences more accessible. In addition, we will explore some of the recent additions in ARIA 1.1, as well as some particular challenges when it comes to traditional ARIA patterns and assistive technologies on mobile/tablet/touch devices. Evergreen slidedeck at https://patrickhlauke.github.io/aria/presentation/ / https://github.com/patrickhlauke/aria/
Vanilla HTML is limiting and boring. Our clients demand highly engaging and interactive web experiences. And wouldn’t you know, with just a bit of HTML and JavaScript we can craft amazing custom controls, widgets and effects that go far beyond the confines of traditional static markup. But how can we ensure that these custom experiences are both understandable and usable for people with disabilities, and in particular those using assistive technologies such as screen readers? In this talk, we will look at the basics of making some common custom-built components accessible - covering how browsers and assistive technologies interact, the limitations of HTML, and how ARIA can help make interactive experiences more accessible. In addition, we will explore some of the recent additions in ARIA 1.1, as well as some particular challenges when it comes to traditional ARIA patterns and assistive technologies on mobile/tablet/touch devices. Evergreen slidedeck at https://patrickhlauke.github.io/aria/presentation/ / https://github.com/patrickhlauke/aria/
This document provides an introduction to Accessible Rich Internet Applications (WAI-ARIA). It discusses the need for ARIA to make complex web applications accessible, common ARIA roles and attributes, and best practices for using ARIA. Key points include: ARIA defines roles, states and properties to convey semantics to assistive technologies; common roles include buttons, toggles, and landmarks; and the five rules of ARIA use emphasize using native HTML when possible and ensuring interactive elements are keyboard accessible.
This document provides an introduction to touch and pointer events. It discusses how touch events work on mobile and tablet devices compared to mouse events on desktop. It notes some limitations of relying only on mouse events for touch devices, such as delayed event dispatching and lack of mouse movement tracking. The document then introduces touch events and how they map to mouse events. It provides examples of how to handle both touch and mouse events together to support different input methods. It also discusses some newer pointer events and media queries for detecting input capabilities. Overall, the document aims to help developers make their websites work well across both touch and non-touch environments.