This is our weekly gathering of Mozilla'a Web QA team filled with discussion on our current and future projects, ideas, demos, and fun facts.

https://air.mozilla.org/web-qa-weekly-meeting-20151217/

This is a weekly call with some of the Reps council members to discuss all matters Reps, share best practices and invite Reps to share...

https://air.mozilla.org/reps-weekly-20151217/

https://fundraising.mozilla.org/ab-test-additional-ask-for-some-channels/

"The Wild Path. An Icelandic Adventure. An interactive storytelling experiment with Canvas." is a beautiful demo. We need more demos like this one.

The map trace is synchronized with the text on the screen. The map is defined as SVG but controlled by canvas.

span> class="container">
    span> style="position: absolute; top: 0px; left: 0px;" height="549" width="817">

with:

    this.canvas = (0, h.default) (e, i), this.canvas.style.position = 'absolute', this.canvas.style.top = 0, this.canvas.style.left = 0, this.ctx = this.canvas.getContext('2d', {
      alpha: !1
    }), this.ctx.fillStyle = '#fff', this.ctx.fillRect(0, 0, this.state.width, this.state.height), this.container.appendChild(this.canvas), this.calculateSections(), Array.from(this.props.textContainer.querySelectorAll('img')).forEach(function (e) {
      e.addEventListener('load', function (e) {
        t.calculateSections(),
        t.renderMap()
      })
    })

Images have a load event, triggering these functions.

function(e) {
  t.calculateSections(), t.renderMap()
}

Some sections have an associated zoom given through a data- attribute, aka private to the page. Perfect usage of data-.

span> class="js-section" data-zoom-middle="2">

and also a data-pos

    span> class="js-image" data-pos="0.25" src="img/journey/9.jpg">
    All things come to an end, and so did our journey when we reached the end of the main street in Reykjavik


[…]


    span> class="js-image" data-pos="0.6" src="img/journey/5.jpg">
    I was the geographer, whose mission it was to make a map of a small portion of the country traversed.

All of that is simple. The code is a nice read.

But the best part of it comes from just reading without CSS and JS. We still get a readable text. And it's rare enough these days, that it has to be praised on the tone, yes it's possible.

One nitpick: The lack of spaces in between some words.

Otsukare!

http://www.otsukare.info/2015/12/17/icelandic-travel

Originally posted on the Samsung Open Source Group's blog. This is a good demo video of a browser chrome that Lars Bergstrom has been working...

https://air.mozilla.org/servo-browser/

http://blog.lizardwrangler.com/2015/12/16/a-call-for-the-release-of-bassel-khartabil/

The bi-monthly status review of the Quality team at Mozilla. We showcase new and exciting work on the Mozilla project, highlight ways you can get...

https://air.mozilla.org/quality-team-qa-public-meeting-6/

mconley livehacks on real Firefox bugs while thinking aloud.

https://air.mozilla.org/the-joy-of-coding-episode-38/

Photo by the awesome Mandy Chan

Yesterday I delivered my last planned talk of the year in the Facebook offices in New York as part of the NYCHTML5 Meetup. Here’s the screencast of the presentation.

The “slides” – as they were – are on GitHub using Tinderesque (and looking much better on Mac).

It’s been an amazing year and I feel so happy to have delivered everything I did and encountered so many great events and people.

https://www.christianheilmann.com/2015/12/16/nychtml5-of-standards-de-facto-nonsense-how-you-can-help-browsers-and-what-to-learn-right-now/

There have been a handful of updates to Mozilla's client-side Mercurial tools in the past week and all users are encouraged to pull down the latest commit of mozilla-central and run mach mercurial-setup to ensure their configuration is up to date.

Improvements to mach mercurial-setup include:

• ~ are now used in paths when appropriate
• Mercurial 3.5.2 is now the oldest version you can run without the wizard complaining
• The clone bundles feature is enabled when running Mercurial 3.6
• hg wip is available for configuration
• hgwatchman (make hg status significantly faster via background filesystem watching) is now available on OS X
• x509 host key fingerprints are no longer pinned if your Python and Mercurial version is modern (this pinning exists in Mercurial because old versions of Python don't verify x509 certificates properly)
• 3rd party Mercurial extensions are pulled with extensions disabled (to prevent issues with old, incompatible extensions crashing the hg pull invocation)

The firefoxtree extension has also been updated. It now uses the new namespaces feature of Mercurial so all Firefox labels/names/refs are exposed in a firefoxtree namespace instead of as tags. As part of this change, you will lose old tags created by this extension and will need to re-pull repos to recreate them as namespaced labels. hg log output will now look like the following:

changeset:   332223:0babaa3edcf9
fxtree:      central
parent:      332188:40038a66525f
parent:      332222:c6fc9d77e86f
user:        Carsten "Tomcat" Book <cbook@mozilla.com>
date:        Wed Dec 16 12:01:46 2015 +0100
summary:     merge mozilla-inbound to mozilla-central a=merge

(Note the fxtree line.)

The firefoxtree extension also now works with hg share. i.e. if you hg share from a Firefox repository and hg pull from the source repo or any shared repo, the labels will be updated in every repo. This only works on newly-created shares. If you want to enable this on an existing share, see this comment.

http://gregoryszorc.com/blog/2015/12/16/mozilla-mercurial-extension-updates

I am pleased to announce that Eric Rescorla has been appointed Mozilla Fellow, a vice-president level role created to recognize top technical leadership at Mozilla. This new role is a complement to the organization’s existing Distinguished Engineers award and is distinct from Mozilla’s other existing fellowship programs. As part of Mozilla’s executive leadership team, Eric will provide key technical expertise and representation for Engineering broadly in all aspects of company decision making.

Eric has a long history of important contributions to the Web, both inside and outside Mozilla, and has served as a thought leader across the security community. Much of his work has been on Transport Layer Security (TLS) the foundational security protocol for the Web. He is the former chair of the IETF TLS Working group as well as the editor of the TLS and HTTPS specifications, and is the author of one of the standard books on TLS. He also co-designed Datagram TLS (DTLS) and DTLS-SRTP, the core security protocols for WebRTC, which is bringing voice and video communications directly into the browser. He served on the Internet Architecture Board from 2002 to 2008.

In addition to his technical standards work, Eric has been involved in many other key areas of intersection between technology and policy. In 2007, he served on California Secretary of State Debra Bowen’s Top-to-Bottom Review of the voting systems certified for use in California and in 2014 he was a member of the team which demonstrated security vulnerabilities in X-ray backscatter full-body scanners (advanced imaging technologies). In 2013, he was one of the authors of the Center for Democracy and Technology’s report on the dangers of government restrictions on cryptography. He has also been called upon to advise governments and policy makers broadly on privacy and security topics.

Since joining in 2013, Eric has been a key member of Mozilla’s technical team. He was instrumental in the development of Mozilla’s WebRTC implementation, and worked with Cisco to start OpenH264, which allows open source projects to use the world’s most popular video codec for free. He also played a key role in starting Let’s Encrypt, a free, automated, and open certificate authority which makes it easy for anyone to run a secure website.

The Fellow role places expanded emphasis on driving our mission forward at a technical level to benefit the open Web and moving the industry as a whole towards open technical development. As part of Mozilla’s executive leadership team, Eric will provide key technical expertise and representation for engineering broadly in all aspects of company decision making. He will report directly to me as CTO.

We are pleased to recognize Eric’s achievements and expanded scope with the title of Fellow, the most senior engineering position within the organization. Please join me in welcoming Eric to the executive team at Mozilla.

https://blog.mozilla.org/blog/2015/12/16/announcing-mozilla-fellow-eric-rescorla/

In this blog post I'll lay out what I think procedural macros should look like. I've discussed the syntax elsewhere, and I'll discuss the API we make available to procedural macros in a later blogpost. I've previously outlined the whole scope of changes to the macro system, and this repeats (or contradicts) some of that, with more detail.

Kinds of macros

There are two kinds of procedural macros - function-like macros and attribute macros. The former are functions marked with #[macro] the latter are marked with #[macro_attribute]. The former are used as foo!(tokens), the latter as #[foo] or #[foo(tokens)] attached to an AST node following the usual rules for Rust attributes. #![...] attributes are supported with the obvious semantics.

Function-like macros have the signature:

#[macro]
pub fn foo(TokenStream, &mut MacroContext) -> TokenStream  

Attribute-like macros have the signature:

#[macro_attribute]
pub fn foo(Option, TokenStream, &mut MacroContext) -> TokenStream  

The first, optional stream of tokens is those in the attribute itself (tokens in #[foo(tokens)]). The second TokenStream is the tokens for the AST node the attribute is attached to. The returned TokenStream replaces that AST node, it can parse into zero or more AST nodes (i.e., we replace both the Modifier and Decorator syntax extensions).

We guarantee that the second TokenStream parses as some AST node, the first TokenStream may or may not parse.

The procedural macro should ensure that the returned TokenStream parses in the context of the macro call.

libmacro

libmacro is a new library added to the standard distribution. It is intended to be used primarily by procedural macros. Its contents will be on the same path to stability as other library crates (i.e., everything starts unstable, and we will stabilise items as their utility is proven). libsyntax will remain, but will be an implementation detail of the compiler - procedural macros should not use it and it will not be stabilised (i.e., stable macros must not use it).

The intention is that libmacro will provide a fairly low-level and bare-bones interface. We expect crates in the ecosystem to provide higher level libraries. In particular, libmacro will have no AST concept. It is expected that crates in the wider ecosystem will provide ASTs, and functionality for parsing tokens to AST and building ASTs.

Libmacro will contain token structures (which might be re-exported from libsyntax) and the MacroContext passed to macros. It will contain functionality for:

• tokenising a string,
• quasi-quoting (text and meta-variables to tokens),
• pattern matching on tokens,
• interning strings,
• generating new identifiers with various hygiene options,
• manipulating hygiene information on tokens,
• applying macros (including name resolution),
• manipulating spans (in particular expansion traces and making new spans) and getting location information from spans,
• check state of feature gates and set feature gates to be used on code they generate,
• mark attributes as used,
• issuing error messages, etc.,
• parsing tokens to key/value pairs as found in attributes.

Much of this functionality will be provided as methods on MacroContext.

I'll cover this API in more detail in a future post. Here I'll cover some aspects of tokens and MacroContext.

tokens

There is a lot of scope for designing an efficient and ergonomic token representation. Here is a starting point.

mod tokens {  
    use {Span, HygieneObject, InternedString};

    pub struct TokenStream(Vec);

    impl TokenStream {
        // Methods for adding and removing tokens, etc.
    }

    pub struct TokenTree {
        pub kind: TokenKind,
        pub span: Span,
        pub hygiene: HygieneObject,
    }

    pub enum TokenKind {
        Delimited(Delimiter, Vec),

        // String includes the commenting tokens.
        Comment(String, CommentKind),
        String(String, StringKind),

        Dollar,
        Semicolon,
        Eof,

        Word(InternedString),
        Punctuation(char),
    }

    pub enum Delimiter {
        // { }
        Brace,
        // ( )
        Parenthesis,
        // [ ]
        Bracket,
    }

    pub enum CommentKind {
        Regular,
        InnerDoc,
        OuterDoc,
    }

    pub enum StringKind {
        Regular,
        Raw(usize),
        Byte,
        RawByte(usize),
    }
}

We could store HygieneInformation on TokenKind::Word, rather than on all tokens. We could also possibly store it for ranges of tokens, rather than individual tokens.

I'm not sure if we need to distinguish $ and ;, the former is used for metavariables in macros, the latter for delimiting items and so it is probably useful to distinguish them. It may be worth distinguishing ! and # since they are used in macro uses, though I can't think of an actual use-case.

It may be worth interning string literals. It may not be worth keeping the contents of comments, since this information can be found via the span (we currently do both these things).

I do not believe we need the interpolated non-terminals here.

We should also expose some helper functions. Note that while I expect we can offer stability guarantees (in time) for the data structures. These functions are only stable in their signatures, not the results. These take a TokenTree or &[TokenTree].

• is_keyword
• is_reserved_word
• is_special_ident
• is_operator
• is_ident
• is_path
• metavariables, extracts meta-variables from a TokenStream e.g., foo($x:ident, $y:expr) would give [("x", 2, ident), ("y", 6, expr)] in some structure.

And possibly some convenience functions for building token trees.

MacroContext

The MacroContext fulfills several roles:

• contains information about the contexts in which the macro is defined and is being expanded,
• communicates information about how the macro's result should be used,
• provides access to libmacro functionality which requires some kind of state.

MacroContext is probably a struct, but I expect most fields to be private. It could also be a trait.

Contextual information

Methods for accessing:

• the span of the macro use (note that the TokenStream arguments also have their own spans),
• the span of the macro definition,
• the hygiene context for the use-site and definition site (note that these are opaque objects, again the supplied tokens will also have their own hygiene information),
• any non-expanded attributes on the macro use,
• the kind of AST node that macro expansion must produce,
• the feature gates set where the macro is used,
• if the macro use is inside a safe or unsafe context,
• the delimiters used in a function-like macro.

Properties of returned tokens

• set feature gates for expanded code,
• control how hygiene is treated in expansion.

Other functionality

I'll cover much of this in the later blog post on libmacro. The most important functionality includes issuing error message, warnings, etc. This will include the ability to add notes and suggestions, and to give span information, based on the tokens supplied to the macro.

Staging

Initially, we will support both new procedural macros and old syntax extensions. Both will be unstable; old syntax extensions should cause a deprecation warning recommending new procedural macros. We will being stabilisation (after some time) by stabilising the attributes for procedural macros, then gradually stabilising parts of libmacro. Once enough of this is stable (and we have moved over the internal syntax extensions to the new scheme), we should remove support for old syntax extensions.

Alternatives

We currently support an IdentTT syntax extension which is a function-like macro with an identifier between the macro name and opening delimiter. I would like to cease support for it. However, it is potentially useful for emulating items (e.g., my_struct! foo { ... }), etc. Unfortunately, it is unsatisfactory for this since it can't handle modifiers (e.g., pub my_struct! foo ...), and some authors want to accept tokens other than an identifier after the macro use. I propose that we remove the facility for now. It could be added backwards-compatibly in the future by either adding a new attribute (#[macro_with_ident] or something) or by adding more info to the MacroContext.

MacroContext is a bit heavyweight, it might be better design to split into several smaller traits or structs. However, this would probably make things less ergonomic.

http://www.ncameron.org/blog/procedural-macros-framework/

Mike Blumenkrantz from the Open Source Group at Samsung and Mozilla's Lars Bergstrom show how to run an application using Servo as the browser engine...

https://air.mozilla.org/servo-embedding-abi-testing/

Hello Mozillians!

As you may already know, last Friday – December 11th – we held a new Testday event, for Firefox 44.0 Aurora. 

Results:

• no new issues were found while testing Add-ons Signing and Async Places Transactions – History features
• 1 new issue found while testing Async Places Transactions – Bookmarks feature: 1232006
• 11 bugs were verified: 1204356, 1231055, 1211636, 1204836, 1218041, 1160733, 1171693, 1217586,  366324, 1221275,  1162635
• 4 bugs were triaged:  1232103,  1231120, 1231173, 1212155

We’d like to take this opportunity to thank Iryna Thompson, Bolaram Paul, Survesh, Moin Shaikh, Preethi Dhinesh and the Bangladesh QA Community: Hossain Al Ikram, Rezaul Huque Nayeem, Nazir Ahmed Sabbir, Sajedul Islam, Sashoto Seeam, Khalid Syfullah Zaman, Mohammad Maruf Islam, Fazle Rabbi, Kazi Nuzhat Tasnem, Forhad Hossain, Md.Tarikul Islam Oashi, Mohammed Jawad Ibne Ishaque, Anika Nawar, Tahsan chowdhury akash, Maruf Hasan Shakil, Fahmida Noor, Omar Faruk, Rakibul islam Ratul, Mehnuba Tarannum Promy, Ishak Herock, Shimanto Ahmed, MD. NAZMUS SHAKIB (ROBIN), Mir maruf Hasan Hridoy, Nafis Ahmed Muhit, Fahim Shahriar, Wahiduzzaman Hridoy, Sayed Ibn Masud, Shaily Roy, T.M. Sazzad Hossain, Towkir Ahmed, Ashickur Rahman, Md. Rahimul Islam for getting involved in this event – your help is always greatly appreciated!

Also a big thank you goes to all our active moderators.

Keep an eye on QMO for upcoming events! 

https://quality.mozilla.org/2015/12/firefox-44-0-aurora-testday-results/

http://feer56.blogspot.com/2015/12/upcoming-postings.html

The Monday Project Meeting

https://air.mozilla.org/mozilla-weekly-project-meeting-20151214/

I’ve been asked again and again over the years what the absolute basics of web accessibility are. And while I always thought that it is not so difficult to find resources about these basics, the recurrence of that question prompted me to finally write my own take on this topic. So here it is, my list of absolute web accessibility basics every web developer should know about.

Alternative text for images

One of the questions I get asked the most is “which graphics require alternative text”? The answer to this question has three parts:

1. All img tags require an alt attribute. This goes without exception. Everything else is an error. If you have an img tag in your HTML without an alt attribute, add it now.
2. Every alt attribute has to have a value. And here is where it gets interesting. If the image is important, because it is part of an a tag, for example, it has to have meaningful text. What is a best alt text is still a point of sometimes heated debate, but the guideline is to use best judgement. Describe the image briefly, but avoid the phrase “image of” or “graphic of”. Because screen readers already know it is a graphic. In addition, every image that adds context to the text of a page that is important in understanding the text needs to have meaningful alternative text. If, on the other hand, an image is purely decorative, its alternative text consists of an empty string “”. That is simply alt=””, two consecutive quotes. But the alt attribute has to be there even for these decorative images, it must not be omitted.
3. It is called alt attribute, alternative text, but never alt tag. alt is an attribute, not a HTML tag.

All the above also applies to SVG graphics. And if you’re really modern and use the picture element, the rules apply there, too.

Using proper alternative text does not just help blind and low vision screen reader users. It also helps on mobile where images sometimes cannot be loaded, for example over slow connections. So by implementing proper alternative text, you help many more people than you might initially imagine.

Labeling form fields

Another very common question I get, and a very common error I see on many many web pages even in 2015, concerns the labeling of forms and form fields. In fact, when dealing with many web developers, I am surprised that many don’t even seem to be aware that there is a label element, for example. So here are the most common rules about form field accessibility:

1. Most input elements, as well as the select and textarea elements, need an associated label element that states the purpose. The one exception are those that produce a button, like the types of button, reset, and submit do. But every other, be it text, checkbox, password, radio (button), search etc. require a label element to be present.
2. The association between such an input and label happens by giving the input a unique ID, given by the id attribute on the input, and the label’s for attribute, which points to said ID. To test that your label actually works, click on the label, not the input, select or textarea. Does the said element still get focus? If so, you did things right. This increases the click target for many audiences, including mobile devices where bigger touch targets are always advantageous. And it associates the label text to the input for screen readers unambiguously. Do not, under any circumstances, use the placeholder attribute as the label for an input element! Read here, why.
3. Give button elements inner text, or if it needs to be a graphic, label it properly with alt text that corresponds to what a textual button label would be. See the section on alternative text for images above. Also, as recommended in the MDN article linked to, prefer button elements over html:input type=”button”, because it is more flexible for styling. Also, this is the go-to element if you have anything that is a div or span and that you want to make clickable with hundreds of kilobytes of JavaScript code. So before you do that, use button instead.
4. A series of radio buttons go inside a fieldset element to group them together. The first element inside this fieldset is the legend element that contains the over-arching question or label for this group of choices.
5. Fieldset and Legend should also be used if grouping together different sections of a bigger form for better readability. The fieldset element can take more than just radio button inputs.
6. Label required fields by providing the HTML5 required attribute on the input as well as stating in the label that a form field is required. This can be done by either providing the word “required” as part of the label, or putting explanatory text at the top of the form telling users that fields marked with an asterisk are required. Do not denote required fields only by a different color. Screen reader users won’t be able to recognize those, and color-blind users, which are 8 percent of the worldwide male population, will also have a hard time finding these.
7. Use appropriate input types for e-mail, URL, phone number etc. Mobile users will thank you because these will bring up the correct keyboards for the information asked. Also, it will make evaluation easier for you because the browser will immediately know if the correct information, e. g. a valid e-mail address, was entered. Modern browsers will do that, and if you need to support older browsers, they’ll automatically fall back to text, which is an appropriate fall-back.
8. Make sure keyboard visibility is always guaranteed. If you see a frame appear around a form field when you click inside it, you should also see it appear when you walk through your form using the tab key on your keyboard. If it does not apear, check your :focus and :active stylings for these form fields in your CSS.

If you need something a little more fancy-looking, please do not fall back to using clickable span and div elements. Because if you do that, you’ll have to add roles, state handling, keyboard focusability and acting on key presses all by yourself. If you use form elements and help yourself with some span elements for styling inside the label, for example, you will get all the accessibility for free, including keyboard, screen readers etc.

Document structure

Believe it or not, but at its core, the web is a document-based structure. So even when we create fancy web applications such as Gmail, the heart of it is a document. And there is a lot you can do with documents semantically that will get you usually 80 to 90 percent of the accessibility for free. For example:

Heading structure

Noticed the different headings and sub headings in this blog post? Well, there are elements for that. They are called heading elements. And they give you exactly that, a six level heading structure to denote a main heading, secondary sub headings, and sub headings to those for sub sections, like this one, for example. This gives your document a logical, easy to follow structure. Have you ever wondered how Wikipedia puts together its table of contents for each article? They use the logical heading structure for that, too!The h1 through h6 elements are unambiguous in telling screen readers, search engines and other technologies what the structure of your document is. Do not mix unless the structure requires it, do not skip levels if possible, since that will disrupt the logic. And never ever again use something like a div with a class of “heading1” in your code. Screen readers, search engines, and other technologies will not know what to do with those. They will know how to treat your headings properly, though!

Landmarks

There are some more ways to structure your document’s contents. By landmarks, for example. Landmarks can be article, aside, footer, header, nav and main. Adding such landmarks appropriately can help further provide sense to your document and help users more easily navigate it.

Lists

HTML knows a whole bunch about lists. There are unordered and ordered lists that are exactly what you’d expect them to be. You can add numbering schemes, even nest them, and the browser will do the rest for you. You can style them the way you want them to look in CSS and thus provide even more structure and meaning to your document’s content. You’ve already seen ordered (numbered) lists in this blog post.

There is also a list type for definition term and explanation groups. The MDN page on the dl element has some great examples of use.

Others

Did you know that HTML has an element to denote paragraphs? It is called the p element. For long citations that require their own paragraphs, use blockquote. For short, inline, quotes, use the q element. Visual separators can be inserted via the hr element.

For all these elements, use CSS to define indentation, separation between paragraphs etc. Those will not impact the semantics, but you are then free to adjust the visuals to your liking or your client’s requirements.

Tables

Tables are its own special case. So much can go wrong, and historically, so much abuse has happened to this poor table element and its sub elements! Especially layouts were done for a long time using tables, before HTML 4 and the onset of CSS. But I still find in modern web applications in 2015, cases where layout tables are being used to align form fields and their labels to one another. STOP DOING THAT! PLEASE!

The table element is a very useful element for creating data representations. Product detail listings, price lists etc. Also, shopping carts with quantities, sub totals and totals, and many other structured data collections can, and should, be put into data tables. Here are some tips to help you:

1. Add a caption element to give the table a proper heading or summary.
2. Use th elements to denote column and row headings. Make use of their scope and other attributes to clearly associate what belongs to which.
3. Use other structural table elements denoted in the “see also” section of the table element documentation to further structure your table.
4. If a table gets too complex or has multiple sections that don’t necessarily have to be in one table, split them up into several data tables.

For more information, I’d like to refer you to the friends at WebAIM who have put together a very good two-pager on the accessibility of HTML tables.

Some more quickies

Here are some more things you can quickly check and make sure when you write HTML, CSS and JavaScript.

Separation of concepts

HTML defines your content structure. It is what screen readers and other assistive technologies use to represent your content to their users.

CSS defines how that content looks visually. Its positioning, indentation, padding, margins usually have no bearing on what screen readers render to the user, with one exception: If display: none; or visibility: hidden; styles are used, that content will also not be available to assistive technologies. See my post titled “Hiding content untagled” for more information.

Also, CSS :before and :after text is rendered to assistive technologies. So be aware what you put in there.

JavaScript adds dynamic functionality. Its output must be proper HTML and CSS, too, if it manipulates the DOM. JavaScript dynamics in itself are no problem to accessibility, only some specific behaviors can be, like losing keyboard focus.

The clearer you separate the three, the more maintainable your code will be. Put CSS in their own files, don’t embed it in the HTML. Put JS modules in their files and don’t embed JS code in your HTML, either. This will make everything more readable, and remind you that the concepts should really be separate that just happen to work together rather than mingling uncontrollably.

Color contrast

Have you ever stood in the sunlight or another bright light source with your smartphone or tablet in hand and wondered why you couldn’t read something? Well, you were suffering from a lack of contrast between foreground and background on the page you were visiting. Low contrast ratios lead to bad readability in bright light situations. For the aging population, as well as low-vision users, low contrasts pose an even greater obstacle in readability. The Web Content Accessibility Guidelines define as a success criteria to have a contrast ratio of 4.5:1 on main content text to its background. You can use tools like the Colour Contrast Analyser to point at your content and see whether your visuals meet this requirement. Even if you’re not auditing for WCAG compliance, adhering to this rule of thumb is still a good idea for your own eyes as well as everyone else’s.

Keep Pinch alive!

When you develop for the mobile web, and today it is most likely you are, please keep the Pinch To Zoom gesture alive! Do not disable this gesture vital to many more of your readers than you might think! Pinching to zoom something small on a web page is very common and does not apply only to aging readers as well as those with low vision. If your layout does not cope with the pinch gesture for some reason, you need to revisit your responsive design and fix it. Do not disable the pinch gesture on mobile browsers!

OK, but what about advanced widgets?

If you really need to implement advanced widgets that are not indiginous to HTML, take good care that you implement all aspects of them. I have some information on how to make clickable widgets that should be buttons or links, tabs and tabpanels, some auto-complete widgets and modal dialogs accessible. The friends at SSB Bart Group have a quite current post on ARIA tree views up, and Terrill Thompson conducted an extensive test of ARIA menus.

It is all in the semantics

As you may have guessed by now, adhering to semantic structures that HTML already offers today will get you a long long way towards accessible web content. In fact, most web content that doesn’t need special widgets will most probably be over 90% accessible by just using proper semantics and honoring a few extras that are in styling.

Only if you need to use widgets that are not provided by HTML, will you really have to dig deeper and dive into standards like WAI-ARIA. But even its first rule is: Don’t use it if you don’t have to! Just sugar-coating everything with WAI-ARIA attributes you find in Google somewhere will do more harm than good. I promise!

In conclusion

If there’s one wish I have for Christmas from the web developer community at large, it is this: Be good citizens of the web, and learn proper HTML before you even so much as touch any JavaScript framework. Those frameworks are great and offer a lot of features, no doubt. But before you use hundreds of kilobytes of JavaScript to make something clickable, you may want to try if a simple button element doesn’t do the trick just as fine!

Use semantics and save yourselves a lot of extra work, because all the standard elements come with accessibility for free.

Teach others! If you’ve mastered the skills of a good HTML and CSS citizen, teach others! Get involved, contribute your knowledge and share your wisdom! You’ll help at least two more than the obvious ones with every contribution you make!

I hope this article helps a little to clarify how easy it is to gain way over 80%, if not over 90% of accessible web content just by following standards and semantics! Please feel free to share your thoughts in the comments below, and if there is something I missed that you think should belong in this collection, feel free to also let me know, and I’ll add it!

Thank you!

https://www.marcozehe.de/2015/12/14/the-web-accessibility-basics/

During Mozlando last week, I organized a TaskCluster "security game". The goals of this exercise were:

• Learn to think like an attacker
• Develop ideas for monitoring for, preventing, and reacting to attacks
• Share awareness of the security considerations around TaskCluster

The format was fairly simple: participants were given with a number of "tasks" and a set of credentials with a relatively low access level (SCM level 1, or permission to push to try). I added some ground rules to prevent mayhem and to keep the difficulty level reasonable. Several members of the Infosec team participated, along with most of the TaskCluster team and a few Release Engineering folks.

Rules

Most of us have "administrator" credentials which would allow us to accomplish any of these tasks easily. Those credentials are off-limits for the duration of the exercise: no heroku access, no github pushes, no use of your AWS credentials. Only public, read-only access to taskcluster/* Docker Hub repos is allowed, although you are free to push to personal repos, public or private.

What you do have is the client-id red-team with an access key that will be provided on the day of the exercise. It has scope assume:moz-tree:level:1, which is try-level access. If you manage to reveal other credentials during the course of the exercise, you are of course free to use them.

You are permitted to push to try (gaia or gecko) under your own LDAP account. Pushes to sheriffed trees are not allowed.

Do not perform any actions intended to or reasonably likely to cause a denial of service for other TaskCluster users. If something breaks accidentally, we will end the exercise and set about fixing it.

We can consider removing some of these restrictions next time, to model rogue-insider, credential-disclosure, or DoS scenarios.

Tasks

• Make an API request with clientId red-team-target.

• Display the relengapi token used by the relengapi proxy in a task log.

• Submit a task that adds an artifact to a different task.

• Claim, "execute" by logging "OWNED!", and resolve a task with a provisionerId/workerType corresponding to existing infrastructure (docker-worker, generic-worker, funsize, signing, buildbot bridge, etc.)

• From a task, create a process that sends traffic to and continues to do so after the task has ended.

• From a task, cause another host within the AWS VPC to execute arbitrary code.

• Harvest a secret value from a private docker image.

• Via a task, start a shell server on the docker-worker host (outside of the container) and connect to it.

• Create a "malicious" binary (not necessarily Firefox) and sign it with a real Mozilla signing key.

Results

I won't go into detail here, but we were able to accomplish a few of these tasks in the 3 hours or so we spent trying! Most began by extracting secrets from a private docker image -- one of the oldest and most-discouraged ways of using secrets within TaskCluster.

Next Time

I'd like to run an exercise like this at every coincidental work-week (so, every 6 months). We wrote down some ideas for next time.

First, we need to provide better training in advance for people not already familiar with TaskCluster -- Infosec in particular, as they bring a great deal of security and penetration-testing experience to the table. Even for an expert, three hours is not a lot of time to craft and carry out a complicated attack. Next time, we could spread the exercise over the entire week, with the ground rules and targets announced on Monday, some shorter hacking sessions organized during the week, and a summation scheduled for Friday. This would allow ample time for study of the TaskCluster implementation, and for long-running attacks (e.g., trying to exploit a race condition) to execute.

We practice security-in-depth, so some of the vunlerabilities we found could not be further exploited due to an additional layer of security. Next time, we may hypothesize that one of those layers is already broken. For example, we may hypothesize that there is a bug in Docker allowing read access to the host's filesystem, and emulate this by mounting the host's / at /host in docker images for a particular workerType. What attacks might this enable, and how could we protect against them?

Finally, some members of the Infosec team are interested in running this kind of exercise much more frequently, for other services. Imagine spending a day breaking into your new web service with the pros -- it might be easier than you think!

http://code.v.igoro.us/posts/2015/12/taskcluster-sec-exercise.html

Followers of this blog know that I’ve dabbled with HTTP/2 stuff for quite some time, and curl got its initial support for the new protocol version already in September 2013.

curl shipped “proper” HTTP/2 support as it looks in the final specification both for the command line tool and the libcurl library before any browsers did in their release versions. (Firefox was the first browser to ship HTTP/2 in a release version, followed by Chrome. Both did this in the beginning of 2015.)

libcurl features an option that lets the application to select HTTP version to use, and that includes HTTP/2 since back then. The command line tool got a corresponding command line option (aptly named –http2) to switch on this protocol version.

This goes hand in hand with curl’s general philosophy that it just does the basics and you have to specifically switch on more features and tell it to enable things you want to use. This conservative approach makes it very reliable protocol-wise and provides applications a very large level of control. The downside is of course that fewer people switch on certain features since they’re just not aware of them. Or as in this case with HTTP/2, it also complicates matters that only a subset of users still have a HTTP/2 tool and library since they might still run outdated versions or they may run recent versions that were built without the necessary prerequisites present (basically the nghttp2 library).

By default?

libcurl is even more conservative that the curl tool so switching default for the library isn’t really on the agenda yet. We are very careful of modifying behavior so we’re saving that for later but what about upping the curl tool a notch?

We could switch the default to use HTTP/2 as soon as the tool has the powers built-in. But for regular clear text HTTP, using the Upgrade: header has a few drawbacks. It makes the requests larger, it complicates matter somewhat that most servers don’t do upgrades on HTTP POST requests (and a few others) so there might indeed be several requests before an upgrade is actually made even on a server that supports HTTP/2 and perhaps the strongest reason: we already found servers that (wrongly, I would claim) reject requests with Upgrade: headers they don’t understand. All this taken together, Upgrade over HTTP will break too many requests that work with HTTP 1.1. And then we haven’t even considered how the breakage situation will be when using explicit or transparent proxies…

By default!

To help users with this problem of HTTP upgrades not being feasible by default, we’ve just landed a new alternative to the “set HTTP version” that only sets HTTP/2 for HTTPS requests and leaves it to HTTP/1.1 for clear text HTTP requests. This option will ship in the next release, to be called 7.47.0, and can of course be tested out before that with git or daily snapshot builds.

Setting this option is next to risk-free, as the HTTP/2 negotiation in TLS is based on one or two TLS extensions (NPN and ALPN) that both have proper fallbacks to 1.1.

Said and done. The curl tool now sets this option. Using the curl tool on a HTTPS:// URL will from now on use HTTP/2 by default as soon as both the libcurl it uses and the server it connects to support HTTP/2!

We will of course keep our eyes and ears open to see if this causes any problems. Let us know what you see!

http://daniel.haxx.se/blog/2015/12/14/curl-and-http2-by-default/

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us an email! Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

This week's edition was edited by: nasa42, brson, and llogiq.

Updates from Rust Community

News & Blog Posts

• Announcing Rust 1.5.
• Building an iOS app in Rust, Part 3. Passing owned objects between Rust and iOS.
• Writing an OS in Rust: Accessing and modifying page tables. Part of the series Writing an OS in Rust.
• Rust programming: Creating a Phoronix reader application
• Macro plans - syntax. Proposal to improve the syntax for Rust macros.
• Zero-runtime-cost mixed list in Rust.
• ArcadeRS 1.10: Asteroid attack!. Part of the series ArcadeRS 1.0: The project - a series whose objective is to explore the Rust programming language and ecosystem through the development of a simple, old-school shooter.
• Rust profiling with instruments and FlameGraph on OSX: CPU/Time.
• Type-Level Shenanigans.
• This Week in Redox OS 8.

Notable New Crates & Project Updates

• rusty-cheddar. A Rust plugin to automatically generate C-style header files.
• Iomrasc'ala'i. An AI for the game of Go/Weiqi/Baduk written in Rust.

Updates from Rust Core

78 pull requests were merged in the last week.

Notable changes

• Store MIR in crate metadata.
• Cargo: Bump to 0.8.0.
• std: Remove deprecated functionality from 1.5.
• std: Rename thread::catch_panic to panic::recover.
• Adjust the pointer to an unsized field to the correct alignment.

New Contributors

• Brian Bowman
• Daniel Campbell
• Letheed
• petevine
• Tianyi Wang
• Xmasreturns

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

No RFCs were approved this week!

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are:

• Amend RFC 550 with (expanded) abstract specification rather than algorithm.
• Add a IndexAssign trait that allows overloading "indexed assignment" expressions like a[b] = c.
• Allow eliding more type parameters.
• Add thread-local custom panic handlers to customize the behavior of thread panics.
• Allow a custom panic handler.
• Add an alias attribute to #[link] and -l.

New RFCs

• Provide a syntactic sugar to automatically implement a given trait Tr using a pre-existing type implementing Tr.
• Amend 0809 to reduce the number of traits.

Upcoming Events

• 12/15. Rust - Rethinking Systems Programming.
• 12/16. SSD Rust meetup - servo + TBD topics.
• 12/21. Paris - Rust Paris.
• 12/23. RustBerlin Hack and Learn.

If you are running a Rust event please add it to the calendar to get it mentioned here. Email Erick Tryzelaar or Brian Anderson for access.

fn work(on: RustProject) -> Money

• Research Engineer - Servo at Mozilla.
• Senior Research Engineer - Rust at Mozilla.
• Open Source Software Engineer at MaidSafe.
• Software Engineer - Sensor Development at IronNet Cybersecurity.

Tweet us at @ThisWeekInRust to get your job offers listed here!

Crate of the Week

This week's Crate of the Week is Quick Error – a rust-macro which makes errors easy to write.

Thanks to killercup for the suggestion. Submit your suggestions for next week!

Quote of the Week

how do cats arbitrate access to a shared typesetting system?

with a mew-TeX

— Nathaniel Theis on Twitter

Thanks to Paul for the tip.

Submit your quotes for next week!

http://this-week-in-rust.org/blog/2015/12/14/this-week-in-rust-109/