Skip to content

Instantly share code, notes, and snippets.

View MelSumner's full-sized avatar
💭
Making the world a more sensible place.

Melanie Sumner MelSumner

💭
Making the world a more sensible place.
View GitHub Profile

The aria-live attribute should be used with extreme caution, as it can provide an incredibly poor user experience for users with assistive technology.

Because the aria-live attribute can be used on any HTML element, and effects all child elements of the element marked with the attribute, a thorough understanding of how this role works and when to use it is especially necessary for competent software engineers who build web-based solutions.

The aria-live attribute can have a few different values (POLITENESS_SETTING): off, polite, and assertive.

Politeness Setting: Off

Assistive technologies should not announce updates unless the assistive technology is currently focused on that region. Regions which contain information that will receive updates but are not critical for users to know about immediately can be marked with aria-live="off". Once that region has (user-driven) focus, the updates will be made known.

@MelSumner
MelSumner / ember-addon-readme-badge-template.md
Created May 3, 2019 20:25 — forked from BrianSipple/ember-addon-readme-badge-template.md
Useful Badges to Include in an Ember Addon's README
[![Latest NPM release][npm-badge]][npm-badge-url]
[![TravisCI Build Status][travis-badge-url]][travis-project-url]
[![CircleCI Build Status][circle-badge]][circle-badge-url]
[![Test Coverage][coveralls-badge]][coveralls-badge-url]
[![Code Climate][codeclimate-badge]][codeclimate-badge-url]
[![Ember Observer Score][ember-observer-badge]][ember-observer-badge-url]
[![License][license-badge]][license-badge-url]
[![Dependencies][dependencies-badge]][dependencies-badge-url] 
[![Dev Dependencies][devDependencies-badge]][devDependencies-badge-url]
@MelSumner
MelSumner / easy-ember.md
Last active December 18, 2018 16:05
A step-by-step guide to setting up a website with Ember.

Initial Setup

  1. Install Ember - npm install -g ember-cli@3.4.4
  2. Create a new app - ember new my-app
  3. Change to the app directory - cd my-app
  4. Install Sass support - ember install ember-cli-sass
  5. Change the app.css file to app.scss - git mv app/styles/app.css app/styles/app.scss
  6. Start your server on the first available port - ember s -p 0
  7. Confirm that everything looks ok in your browser. You should see the "Congratulations, you made it!" message on the home page
  8. Stop your server in your terminal window by pressing CTRL + C
├── INDEX (home)
├── DOCS
|   ├── Ember.js Guides
|   ├── ember-cli Guides
|   ├── (ember-data guides)
|   ├── Ember.js API 
|   ├── (ember-cli API)
|   ├── (ember-data API)
| └── Learn Ember
@MelSumner
MelSumner / controllers.application.js
Last active November 13, 2018 22:09 — forked from sukima/controllers.application.js
table cell links semantic HTML
import Ember from 'ember';
export default Ember.Controller.extend({
appName: 'Ember Twiddle',
actions: {
transitionToShow(routeName) {
this.transitionToRoute(routeName);
}
}

Accessible by Default - WIP

The purpose of this (gist) is to break down what steps Ember.js would need to take, in order to be considered accessible by default. The goal is to identify what is - and what is not - possible to do "by default".

This document should neither be be considered a criticism of any previous effort nor a dictation of how things must be, but rather a starting point for conversation for where we (as a community) could go.

Assumptions & Introductions

This document assumes that the reader is at least minimally familiar with what digital accessibility is and the existence of the WCAG Guidelines. This proposal uses WCAG 2.1 documentation.

Road to 1.0 - an ember-engines roadmap

These are the items that we envision should be completed in order for the ember-engines project to get to version 1.0. This list should not imply an order or priority; all of these items need to be completed before the project can be considered ready for 1.0.

Lazy Loading for Routeless Engines

The ability to lazily load routed engines has proven to be very useful; we'd like to enable the same capabilities for routeless engines. Some work has already started (see ember-asset-loader issue #56).

These are the tasks to reach that goal:

  • write helper
  • write accompanying tests
/* iframe with the video does have inline styles, but adding this style will fix the issues with the mobile view.*/
iframe {
width: 100%;
}
/* absolutely positioned divs - remove the absolute positioning, add a class called .call-to-action-wrapper (or something) */
.call-to-action-wrapper {
display: block;
clear: both;
width: 100%;
margin: 0 auto;

What I've tried:

  1. added a theme-service in my addon
  2. added a theme-toggle component in my addon ('theme-toggle.js', 'theme-toggle.hbs', 'theme-toggle.scss' (with an underscore in front)
  3. added a themes.scss (as per the blog post)
  4. added both the component.scss file and the themes.scss file to my addon.scss file.
  5. injected the theme service into the route of the page in the dummy app:

context

  • internal UI addon (hosted on something like an internal npm/artifactory)
  • to use- create ember app, add file to package.json, run npm install.
  • next run ember generate my-addon to run a custom blueprint that does some other stuff
  • it would be okay to set the theme once per app, but it would also be awesome if we could make it so the end user could select a theme from a settings menu (too ambitious?)

options for theming

  • use ember-theme-changer addon?
  • add the option to the blueprint that they have to already run anyway?